Discussion :

[kaymak]

hello,

suivant la ml depuis quelque temps maintenant, j'aurais tendance à dire, que les problèmes simple sont résolus rapidement, mais les trucs compliqués, sa reste un peu au petit bonheur la chance.. Hors comme c'est un framework taillé pour faire des gros projets, on aura nécessairement des cas qui sorte des sentiers battus, du cas d'école de blog etc Donc c'est d'autant plus important de pouvoir trouver des réponses à ce genre de questions.
Sauf si bien sûr on à de l'argent à claquer dans les services proposés par la société sensio.

Par contre :

Le code source est quand à lui bien fait ce qui permet de se plonger dedans pour essayer de mieux comprendre certaine mécanique

Moi j'ai l'impression, mais je ne dois pas assez le pratiquer, que la DI à tendance à rendre les interactions entre les classes plus confuses.

fin bon, quand je vois qu'il faut activer, at least, 500 niveaux de récursion, je me pose des questions. Vu sur la ml ce jour.

a+

[gilwath]

bah je trouve pas que le DI rends les choses plus confuse, limite plus clair une fois bien assimilé le principe ( le fait que je sois encore étudiant et que c'est une notions vu en cours de c# ). Après pour les choses compliqué c'est normal que l'on trouve pas encore les ressources le framework est encore jeune

[pingolitipus]

Tout à fait d'accord avec ce qui est marqué au dessus.

Symfony2 oui, mais Doctrine2 ... ou veulent-ils en venir ?

Le systèmes d'annotation me pose aucun problème. Cependant, pour quoi faire ?
La doc est tellement pauvre et n'explique que la base.
Dès que l'on fait une application complexe, aucune explication sur la méthodologie.

...
- Comment faire une requêtes pour vérifier un lien manytomany ?
- Comment éviter de faire des requêtes dans la vue puisque les annotations ne permette plus de faire suivre les requêtes(ex: $user->getClientActifs())
- ...

Bon c des questions cruciales qui me bloque des le départ et qui sont pourtant si importantes! Merci symfony2, doctrine2 tu repasseras ...
Sa sent la formation bien chère sa !!

[FMaz]

Tout à fait d'accord avec ce qui est marqué au dessus.

Symfony2 oui, mais Doctrine2 ... ou veulent-ils en venir ?

Le systèmes d'annotation me pose aucun problème. Cependant, pour quoi faire ?
La doc est tellement pauvre et n'explique que la base.
Dès que l'on fait une application complexe, aucune explication sur la méthodologie.

...
- Comment faire une requêtes pour vérifier un lien manytomany ?
- Comment éviter de faire des requêtes dans la vue puisque les annotations ne permette plus de faire suivre les requêtes(ex: $user->getClientActifs())
- ...

Bon c des questions cruciales qui me bloque des le départ et qui sont pourtant si importantes! Merci symfony2, doctrine2 tu repasseras ...
Sa sent la formation bien chère sa !!

À qui le dis-tu.
Nous avons actuellement choisi Symfony2 pour une application représentant 6 mois de développement à 5 programmeurs (donc pas un blog), et les critiques que tu fais, nous les vivons.

1) Doctrine2 est très limité pour les applications d'envergures (je parle de fonctionnalités), ou alors la documentation est incomplète.

Il y a beaucoup de relations complexes qui ne sont pas bien expliqués dans la documentation de Doctrine2. La plupart du temps, nous devons choisir des compromis qui nous empêche d'avoir une Seconde Forme Normale ( pas 3 ou 4, DEUX !) dans notre base de données.

2) Les messages dans les exceptions sont imprécis
Les messages d'erreurs que retourne Symfony2 ou Doctrine2 sont très loin d'être explicite. Quand on a plusieurs dizaines d'entitées, et qu'on a une erreur telle que:

[Doctrine\DBAL\DBALException]
Unknown column type requested.

--> Un nom de colone était invalide dans la configuratoin de mapping d'une des entitées.

ou encore:

[ErrorException]
Notice: Undefined index: MyVendor\MyApp\GeoBundle\Entity\Address in /Users/fmaz/Site/vendor/doctrine/lib/Doctrine/ORM/Mapping/Driver/AbstractFileDriver.php line 121

--> Celle là je ne m'en souviens pas, mais bon, je vous laisse deviner, c'est clair après tout non ?

ou encore:

ErrorException: Notice: Undefined index: in /Users/fmaz/Site/vendor/doctrine/lib/Doctrine/ORM/Internal/Hydration/SimpleObjectHydrator.php line 92

--> Le nom d'une colonne de discrimination avait une erreur de syntaxe dans la configuration du mapping.

On la trouve pas drôle de passer 3h à chercher d'où ca peut venir faute de détails pertinent.


3) La documentation est incomplète

Un exemple simple, on nous explique bien comment accéder au dependency injection container, ou au doctrine entity manager. Sympa $this->truc, $this->machin, c'est ultra simple! Tant et aussi longtemps qu'on est dans le cadre bien défini d'un controlleur qui extends la classe de base Controller de symfony2.

Et quand on fait des test unitaire ou fonctionnels, on fait comment pour accéder ? C'est là qu'on se rend compte que la mécanique interne est bien peu expliquée. Alors on reverse-engineer pendant des heures. Ouf.



Bref, ce qu'il demeure à améliorer pour Symfony2 et Doctrine2 c'est:
- Des erreurs précises et utiles au développeur.
- Une documentation plus complète avec des exemples concret et complet.

Sinon, le framework est solide et professionnel, ca fait du bien de voir qu'enfin le monde PHP se rapproche du niveau de développement qu'il peut-y avoir en Java (par exemple).

[FMaz]

Et sinon, quel type de requête SQL n'arrives-tu pas à faire ? Comme ça, par curiosité...

La question ne m'étais pas adressée, mais j'ai formulé la même plainte, alors voici la justification :p (je vulgarise mon exemple)

J'ai 2 tables:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
Address
- id
- civicNo
- road
- city
 
personAddress
- id
- personId
- addressId
- type
- isPrimary

Et j'ai évidemment 2 classes: Address et personAddress. ( J'ai aussi businessAddress, organisationAddress, etc... mais on gardera que 2 tables/classe pour l'exemples)

Une adresse peut exister par elle-même, sans être une personAdress.
Une même adresse peut à la fois être utilisée comme personAddress et autre ( businessAddress, etc.. )

Du coup aucune des 3 stratégies d'inheritence proposée par Doctrine2 ne peut satisfaire la réalisation de ces contraintes en respectant la seconde forme normale ( entre autre: ne pas avoir de duplication de données )


Au fait, si jamais tu peux me donner tord et possède une solution, je suis plus qu'à l'écoute

[RapotOR]

Salut FMax,

Je te sens remonté Je comprends un peu ton emballement, j'ai également passé pas mal de temps (je ne dirais pas perdu vu que c'est en même temps de l'apprentissage. doctrine2 n est pas la mise a jour de doctrine1).

Concernant ton soucis, qu'en est il de cette configuration-ci?

Un résumé de tes tables:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
 
Person
- id
- name
 
Address
- id
- civicNo
- road
- city
 
personAddress
- id
- personId
- addressId
- type
- isPrimary

Dans ton entité Person:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
   /**
     * @OneToMany(targetEntity="personAddress", mappedBy="person")
     */
    private $addresses;

Dans ton entité personAddress:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
    /**
     * @ORM\ManyToOne(targetEntity="Person")
     * @ORM\JoinColumn(name="personId", referencedColumnName="id")  
     */
    private $person;
 
     /**
     * @ORM\ManyToOne(targetEntity="Address")
     * @ORM\JoinColumn(name="addressId", referencedColumnName="id")  
     */
    private $address;

Ca donne ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
$user->getAddresses()->getAddress()->getRoad()
$user->getAddresses()->isPrimary()

[pc.bertineau]

Au fait, si jamais tu peux me donner tord et possède une solution, je suis plus qu'à l'écoute

Je n'ai jamais utilisé l'héritage d'entités au niveau du modèle. La doc laisse entendre que le "Class Table Inheritance" serait le plus proche de ton cas... Mais cela impose d'avoir un champ discriminant côté Address, ce qui t'empêche d'associer une adresse à plusieurs classes enfant => aucun intérêt...

J'avoue que ce 3e type d'héritage ne semble pas remplir ses promesses

A part une relation ManyToOne côté classe enfant et effectivement des méthodes Proxy pas très avantageuses, je ne vois pas de meilleur compromis Je préférerai toujours avoir un modèle de données conceptuellement bon et un code qui l'est un peu moins, mais ce n'est qu'un point de vue personnel.

Perso j'ai exclu les entités de l'analyse PHPCPD sur mon serveur d'intégration continue... Je m'en remets à mon sens de la rationalité