Reprise du message précédent :

D'un autre côté le mapping dans des fichiers séparés j'en ai fait l'expérience avec Hibernate à l'époque (avant que Java ait de vraies annotations) et c'est super frustrant, parce que tu te retrouves en permanence à devoir naviguer entre le fichier de mapping (qui en plus était obligatoirement en XML donc imbitable) et le fichier de modèle et à devoir répéter 15 fois les mêmes noms.

Après clairement ça vaut pas de vraies annotations (JPA/Hib 3) ou des objets dédiés (SQLAlchemy, DjangORM), mais je tends à préférer les "annotations en commentaires" (surtout si le parser/compilo est correctement fait et rapporte bien les erreurs) à un fichier de mapping externe, sauf à avoir une très très bonne intégration IDE, parce qu'au final c'est juste encore plus chiant.

 
Tu vas x fois plus vite que si tu devais tout coder, il est là le bénéfice

Ah ben de toute manière quelle que soit la solution ce sera toujours la plaie par rapport à une réelle connaissance de la structure de la base qui permet de construire tranquillement ses objets métier coté appli avec des requêtes écrites à la main, on est d'accord.

 
Lolzor. Au lieu d'écrire des requêtes simples, tu galères à apprendre une syntaxe liée à ton ORM pour que cet abruti réussisse à générer les mêmes requêtes que tu aurais écrites.
Le temps que tu gagnes d'un coté (un jour, peut-être), tu le perds de l'autre en grande partie.

tu as vachement testé pour dire ça. Voici le formulaire le plus complexe  (sf1.4, doctrine 1 ) que j'ai dans une appli, à cheval sur 3 tables

/**/
class ActiviteDureeForm extends ActiviteForm{
    public function configure()
    {
        parent::configure();
        $this->embedRelation('ActiviteAgent','ActiviteAgentDureeForm');
        $this->useFields(array( 'name','structure_id','type_activite_id', 'ActiviteAgent'));
 
    }
 
}

il permet de créer une activité et d'y rattacher un nombre quelconque d'agent
Il permet aussi de modifier une activité existante

Je n'ai pas de code a te montrer pour la sauvegarde vu qu'il n'y en a pas. Tout est géré par le FW.
Il ne manque que les validator de process métiers, que je n'ai pas copié ici , mais qui s'intègrent très facilement

LA définition du schéma est effectivement extremement complexe

---
detect_relations: true
options:
  collation: utf8_general_ci
  charset: utf8
  type: InnoDB
 
Activite:
  columns:
    id:
      type: integer(4)
      primary: true
      default: null
      notnull: true
      autoincrement: true
    name:  string(255)
    type_activite_id: integer(4)
    structure_id: integer(4)
    reference: string(255)
    debut: timestamp
    fin: timestamp
    duree: integer # duree réelle de l'activite
    duree_indemnise: integer # durée indemnisé au taux plein ( exemple pour la dispo , duree indemnisée a 3% ) 
    cout: integer
  indexes:
    idtypesactivites_idx:
      fields: [type_activite_id]
    idstructures_idx:
      fields: [structure_id]
    reference_idx:
      fields: [reference]
  options:
    charset: utf8
    type: InnoDB
    
 
 
ActiviteAgent:
 
  columns:
    id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: true
    activite_id: integer(4)
    agent_id: integer(4)
    debut: timestamp
    fin: timestamp
    duree: integer # duree réelle de l'activite
    duree_indemnise: integer # durée indemnisé au taux plein ( exemple pour la dispo , duree indemnisée a 3% ) 
    cout: integer
    type_paiement:
        type: enum
        values: ['payé','non payé','subrogation']
    statut_paiement:
      type: enum
      values: ['','transmis Civitas']
  indexes:
    idactivites_idx:
      fields: [activite_id]
    idagents_idx:
      fields: [agent_id]
  options:
    charset: utf8
    type: InnoDB
    
Agent:
  columns:
    id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: true
    matricule:
      type: integer(4)
      unique: true
      notnull: true
    nom:  string(45)
    prenom: string(45)
  options:
    charset: utf8
    type: InnoDB

Cette définiton crée automatiquement les validations basiques des formulaire ( not null, bon format,.. )

l'usage en sous forme de query builder donne ça :

$query = $this->createQuery('aa')
            ->innerJoin('aa.ActiviteAgentIndemnisation aai')
            ->select('aa.*,aai.id as aai_paye')
            ->orderBy('aa.debut');
 
        if ($annee_paye) {
            $query = $query->andWhere('YEAR(date_indemnisation)= ?', $annee_paye);
        }
        if ($mois_paye) {
            $query = $query->andWhere('MONTH(date_indemnisation) = ?', $mois_paye);
        }
        if ($agent || $structure) {
            if ($agent) {
                $query = $query->andWhere('aa.agent_id = ?', $agent->getId());
            }
            if ($structure) {
                $query = $query->innerJoin('aa.Activite a');
                $query = $query->andWhere('a.structure_id = ?', $structure->getId());
            }
        }

C'est sûr que c'est extremement complexe
Truc confortable : je défini tout le morceaux communs au début (order et limit y compris ) ensuite, je colle les morceaux dont j'ai besoin, y compris des jointures

EDIT : pour le franglais, je sais, mais c'est une contrainte qu'on m'a imposé ici

/**/
class ActiviteDureeForm extends ActiviteForm{
    public function configure()
    {
        parent::configure();
        $this->embedRelation('ActiviteAgent','ActiviteAgentDureeForm');
        $this->useFields(array( 'name','structure_id','type_activite_id', 'ActiviteAgent'));
 
    }
 
}

Ah ben c'est sûr que si c'est ça que tu appelles un formulaire complexe, effectivement.

Tu veux ajouter 4 autres tables liées ?
Ca ne coûte rien de plus.

Tu veux faire une validation ? L
a moitié est construite automatiquement par doctrine, il ne te reste plus que celle spécifique à ton métier, avec les bons points d'entrées
Ca te génère même un template HTML adapté pour simplifier l'intégration

EDIT : bien sûr, j'imagine que TOI , tu bosses sur des choses réellement complexe.
 

 
Pourquoi se faire chier à apprendre la syntaxe et l'archi d'un framework alors que tu pourrais coder le tiens ?
 

 
Sous sf 1.4 j'avais des formulaires autrement plus complexe, avec des surcharges des doUpdates, doSave, doBind, etc.
 

 
J'espère qu'il troll et qu'il n'est pas convaincu de ce qu'il dit

On a dû se taper des trucs avec sous-formulaires, possibilité d'ajouter de nouveaux enregistrements dans les tables liées + des traductions en N langues...le tout sans avoir le droit de découper.
Dans mon souvenir c'était la plaie à faire avec leur machin - en SF2, si ça change quelque chose.

 
Quel rapport?
 

Non.

J'ai des trucs comme ça  

public function doBind(array $values) {
        
        $values['sf_guard_user_id'] = sfContext::getInstance()->getUser()->getGuardUser()->getId();
 
        parent::doBind($values);
    }

Mais  ça va, j'ai pas trop eu a abuser de doUpdate/save  
Par contre j'ai deux validators dont je suis assez content

Enfin ça c'est aussi merdique a gérer correctement sans FW
La je viens de te montrer un formulaire avec des sous formulaires pour lesquels il y a possibilité d'ajotuer/d'effacer/ de mettre à jour  et qui enregistre dans 3 tables . C'est pas loin de ce que tu décris, et c'est loin de ce qu'on te cite comme avantage : gagner du temps quand c'est simple pour pouvoir se concentrer sur les parties vraiment complexe.

A noter que même dans symfony 2 tu peux faire le choix de monter le formulaire  de le valider à la main en disant  fuck à doctrine. Le choix de l'outil est laissé au développeur.

J'avais laissé le collègue faire le choix, là-dessus - il voulait tester SF2 et doctrine, j'ai suivi. Comme quoi je suis pas si borné que j'en ai l'air.

On ne s'est  pas compris
Tu peux utiliser SF2 (ou SF1, ou CI ) et doctrine (ou propel), mais passer en mode manuel de temps en temps, par exemple sur un formulaire infect ou une requete cruciale
 

 
Ah, ça oui.  
Mais quand tu testes un FW t'as tendance à vouloir les triturer pour tout faire avec - en tout cas moi oui. Et ça m'énerve grandement de me rendre compte que le truc ne sait pas faire ce que je veux obtenir sans le rendre inutilement complexe.

quand tu as un marteau à la main, tout ressemble à un clou

Mais c'est pas la faute du FW.

Bon en tous cas toi tu m'as convaincu définitivement

 
La doc me dit "pour faire un formulaire, c'est comme ça:". En phase d'apprentissage, je suis bête et discipliné.

Il y a un vrai apprentissage quand même au début, sinon tu risques de passer à côté du fonctionnement
 
Le formulaire que j'ai montré en est un bon exemple, je l'avais complètement remonté à la main, parcque  je n'avais pas compris la difference entre fromArray et synchronizeWithArray()  
 
Pour l'ORM part plutôt avec propel pour du SF2. A minima, ça te permettra d'envoyer un CV a ratibus et c'est ce qu'avais conseillé le formateur ( hugo hamond )

Non, c'est complètement con ce que tu dis, tu peux aussi bien te souvenir de tous tes mappings et si t'y arrives grand bien t'en fasse. Perso j'arrive pas à garder tous les types de toutes mes applications en tête en permanence, db ou pas db, donc dans tous les cas je dois me référer régulièrement à la source

Ouais, le collègue utilisait propel avec SF1 si mes souvenirs sont bons.
J'imagine que sans passer par une vraie formation payante au lieu de fouiller la doc tu rates des trucs de toute manière...

Bof, j'ai fait la formation payante (niveau avancé , SF2) et je n'y ai pas appris grand chose
 
A la limite, il vaut mieux faire un mini projet à la con

La même, avec en plus le passage de la 2.0 à la 2.1 : de quoi ? Sur une version mineure ils changent totalement le système de gestion de paquets et l'API des formulaires. Classe.

 
Pour le coup je vois pas le rapport avec l'ORM (ou pas).

A-t-il cité une raison spécifique ? Genre c'est ce qui va être favorisé dans le futur ?

C'est ce qu'on a fait - au final c'est une appli toute petite le truc dont je parlais, avec comme difficultés seulement 2/3 formulaires à la con et les emmerdes liées au multilingues.
bah au final je pense pas repartir vers du SF2 sans faire une bonne formation payante pour être sûr de rien avoir raté en route, parce-que là au lieu de m'aider sur les trucs compliqués ça m'a donné l'impression de vouloir faciliter les trucs déjà simples mais de rendre les trucs compliqués encore pires.

oui
mais c'était il y a quasiment un an, ça a pu changer depuis

Le même que le truc auquel ça répond: strictement aucun.

Je te dis que le fichier de mapping séparé c'est lourd parce qu'il faut naviguer entre 2+ fichiers pour avoir toutes les infos donc je préfère les annotations ou dédiés qui ont tout au même endroit, ta réponse est complètement à côté de la plaque.

Je disais que l'ORM est de toute manière une couche supplémentaire casse-couilles à configurer/maintenir quel que soit l'outil de configuration par rapport à une couche model "old-school" avec des requêtes à la main. Je vois un rapport avec l'ORM, moi.

Donc tu réponds un truc qui n'a aucun rapport avec le truc auquel tu réponds? Et accessoirement, ta couche model "old school" avec requêtes à la main elle va pas non plus se maintenir toute seule

 
Evidemment. Mais ça me parait beaucoup plus simple à gérer que des annotations @ORM.

Dans le cookbook de la 2.1, ils parlent surtout de Doctrine. J'vais faire encore des recherches

En quoi? Au lieu de maintenir des annotations, tu dois aller chasser les requêtes SQL dans des chaînes à travers le truc à la place.

J'ai pas à me demander quelle syntaxe à la con je dois utiliser pour exprimer ce que je veux, déjà.

Bon moi de toute manière, quelque soit le truc : taper des requêtes à la main, générer à partir d'un fichier XML, générer à partir d'une classe, avoir une API rigolote, le problème vient toujours du merdier sous-jacent : ces putains de DB relationnelles qui n'offrent que des vulgaires tableaux pour tout stocker.
 
Rien que pour une simple hiérarchie, y'a 25 solutions aussi nulles les unes que les autres. Pour l'héritage/extension de type c'est pareil. Ça ne correspond plus du tout à ce qu'on a au-dessus, à savoir des langages objets

 
Il m'a fallut 4 mois pour bien maîtriser SF1.4, avec l'aide de bons devs IRL. Pas besoin de formation, et si tu te poses une questions tu regardes les sources.
 

 
+1.
Et pour ceux qui sont gênés par les annotations en commentaire il est tout à fait possible de le faire en PHP, directement dans la fonction.
 

 
J'ai l'impression que c'est toujours Doctrine qui a été mis en avant (d'un autre côté c'est l'ORM de Sensio ), mais j'entends beaucoup de bien de Propel notamment avec les "criterias".

...le problème c'est que ça résume bien le fonctionnement des gros framewroks php, ZF est pareil...

J'ai pas encore vu de DBO qui ressemblait à quelque chose
 
Mais tu peux utiliser une db non rel, genre redis. Ou des fonctionalités nonrel dans un RDBMS, genre hstore ou les arrays de postgres

Shit. On s'y met

/**/
class ActiviteDureeForm extends ActiviteForm{
    public function configure()
    {
        parent::configure();
        $this->embedRelation('ActiviteAgent','ActiviteAgentDureeForm');
        $this->useFields(array( 'name','structure_id','type_activite_id', 'ActiviteAgent'));
 
    }
 
}

---
detect_relations: true
options:
  collation: utf8_general_ci
  charset: utf8
  type: InnoDB
 
Activite:
  columns:
    id:
      type: integer(4)
      primary: true
      default: null
      notnull: true
      autoincrement: true
    name:  string(255)
    type_activite_id: integer(4)
    structure_id: integer(4)
    reference: string(255)
    debut: timestamp
    fin: timestamp
    duree: integer # duree réelle de l'activite
    duree_indemnise: integer # durée indemnisé au taux plein ( exemple pour la dispo , duree indemnisée a 3% ) 
    cout: integer
  indexes:
    idtypesactivites_idx:
      fields: [type_activite_id]
    idstructures_idx:
      fields: [structure_id]
    reference_idx:
      fields: [reference]
  options:
    charset: utf8
    type: InnoDB
    
 
 
ActiviteAgent:
 
  columns:
    id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: true
    activite_id: integer(4)
    agent_id: integer(4)
    debut: timestamp
    fin: timestamp
    duree: integer # duree réelle de l'activite
    duree_indemnise: integer # durée indemnisé au taux plein ( exemple pour la dispo , duree indemnisée a 3% ) 
    cout: integer
    type_paiement:
        type: enum
        values: ['payé','non payé','subrogation']
    statut_paiement:
      type: enum
      values: ['','transmis Civitas']
  indexes:
    idactivites_idx:
      fields: [activite_id]
    idagents_idx:
      fields: [agent_id]
  options:
    charset: utf8
    type: InnoDB
    
Agent:
  columns:
    id:
      type: integer(4)
      primary: true
      notnull: true
      autoincrement: true
    matricule:
      type: integer(4)
      unique: true
      notnull: true
    nom:  string(45)
    prenom: string(45)
  options:
    charset: utf8
    type: InnoDB

$query = $this->createQuery('aa')
            ->innerJoin('aa.ActiviteAgentIndemnisation aai')
            ->select('aa.*,aai.id as aai_paye')
            ->orderBy('aa.debut');
 
        if ($annee_paye) {
            $query = $query->andWhere('YEAR(date_indemnisation)= ?', $annee_paye);
        }
        if ($mois_paye) {
            $query = $query->andWhere('MONTH(date_indemnisation) = ?', $mois_paye);
        }
        if ($agent || $structure) {
            if ($agent) {
                $query = $query->andWhere('aa.agent_id = ?', $agent->getId());
            }
            if ($structure) {
                $query = $query->innerJoin('aa.Activite a');
                $query = $query->andWhere('a.structure_id = ?', $structure->getId());
            }
        }

Tu peux virer la ligne 12

Sinon tu regardes ce qui existe en !php aussi, ça peut être bien