Discussion :

[Nek.dev]

Moi je pense que c'est juste pas assez documenté. Pour l'instant l'utiliser est une perte de temps pure et simple.

La communauté n'est pas assez grande autour du framework pour qu'on se débrouille bien à l'heure actuelle.

[winzou]

Moi je pense que c'est juste pas assez documenté.

D'accord la dessus, mais bon ca va venir il faut pas s'inquiéter.

Pour l'instant l'utiliser est une perte de temps pure et simple.

Absolument pas d'accord. Il faut tellement de temps pour être à l'aise avec un framework de cette taille, commencer maintenant n'est pas du tout une perte de temps. Car si la documentation ne traite pas encore tous les points délicats, elle traite tous les points de base qu'il faut maitriser parfaitement avant de passer à la suite. Tu as donc du pain sur la planche, dès maintenant, et du pain qui va te servir par la suite.

La communauté n'est pas assez grande autour du framework pour qu'on se débrouille bien à l'heure actuelle.

Absolument pas d'accord non plus. La communauté est assez énorme autour de Symfony2. Un des des plus gros projets sur github ! Une mailing liste bien remplie avec des intervenants de qualité. Des forums qui en parlent un peu partout. Des blogs dédiés à symfony2 dans tous les sens sur le web. Etc.

[gilwath]

Moi je pense que c'est juste pas assez documenté. Pour l'instant l'utiliser est une perte de temps pure et simple.

La communauté n'est pas assez grande autour du framework pour qu'on se débrouille bien à l'heure actuelle.

Tout d'abord la doc actuelle je la trouve plutôt complète, et y a de plus en plus de cookbook qui arrive, de plus la communauté est assez réactive, rien qu'à voir sur irc, tu pose une question et hop tu as généralement ta réponse rapidement. Le code source est quand à lui bien fait ce qui permet de se plonger dedans pour essayer de mieux comprendre certaine mécanique

[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

[kdmbella]

Mauvaise nouvelle (ou pas?) également de ce côté. Hugo Hamon nous a dit que symfony 1.x avait été sur-documenté et, qu'au final, les gens se perdaient à chercher les infos car il y avait trop de livres dessus.

Bien évidemment, l'emploi du conditionnel a été employé, mais visiblement, il n'y aurait qu'un livre qui sortirait, et qui serait l'équivalent papier de la version en ligne que l'on trouve ici: http://symfony.com/doc/current/book/index.html

je préfère qu'il y ai un livre car ça empêche effectivement de se dispercer
mais j'attache un point d'honneur au tuto pratique à la jobeet car un exemple ça vaut 100 fois mieux qu'un long livre (#discours) et ça a le mérite de te rendre opérationnel assez rapidement

[gilwath]

Bah personnellement je trouve que la docs sous sa forme actuelle est beaucoup plus pratique et agréable a utiliser que pouvait l'être jobeet par exemple, un tuto tu finis vite par te perdre. De toute façon il est plus logique que sur le site officiel il y ai la doc sous sa forme officiel, et que l'on va trouver une multitude de jobeetlike sur le net

[Jackris]

J'ai commencer Symfony 2 il y a 15 jours apres 6 mois de CodeIgniter, je vois effectivement une grosse différence et aussi une grande éfficacité quand on a assimiler le concept, je doit etre a 10% de ses fonctionnalités mais bon je triffouille et je trouve des trucs

La doc j'aime pas trop sa présentation m'enfin google m'aide les 3/4 du temps.

[scrappilly]

Voilà j'ai voulu développer avec symfony2 un site tout simple, mais je me rend compte que je perd énormément de temps à chercher des infos, les 2 tutos de Jérome Laplace m'ont bien aidé au début, mais maintenant c'est une catastrophe, je perd beaucoup de temps, je pensais que j'allais en gagner si j'utilisais un framework plutôt que tout développer en php, mais non c'est le contraire.

Doctrine2 est bien mais il prend pas en compte toutes les requêtes, donc utiliser sql natif (21/2 journée pour trouver les infos et que ça marche), ...
Twig est lui aussi limité et je n'arrive pas à utiliser des fichiers php ou html, car il me réclame des template twig ...

Donc pour l'instant je termine ce site et je repars en pur php, on verra peut-être plus tard si je m'y remets.

[pc.bertineau]

Il faut plusieurs mois pour prendre en main un framework. Pour Symfony2 c'est même plus global, il introduit des concepts (design patterns notamment) qui étaient peu connus des développeurs PHP, provenant du monde des langages purement objet (Java).

Le tout fait qu'il y a beaucoup de choses à comprendre/assimiler, donc plus de temps. Je dirais que pour un site perso, tu t'en passeras très bien.
Pour travailler en entreprise, l'utilisation d'un framework apporte une chose souvent négligée mais d'une importance immense : une norme de codage, des bonnes pratiques, une philosophie commune aux développements...

Et si tu baignes entre les 2 (perso et pro) : Symfony2 pour les devs pro ou gros projets en général, Silex (framework plus léger s'appuyant sur des composants de Sf2) pour les plus petits projets => tu mutualises ton temps d'apprentissage du framework.

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

[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()

[FMaz]

Hehe, salut RapotOR
Remonté, moi ? Bah, juste québecois (donc direct).

Ce que tu propose, c'est la première chose que j'ai essayé, mais c'est très peu pratique au niveau du code, puisqu'il n'y a aucune raison pour qu'il faille faire un getAddress() sur un objet qui est déjà une adresse ! Il faudrait alors que je fasse une tonne de méthode dites "proxy", ce que phpcpd n'aimera vraiment pas (et moi non plus d'ailleurs). ou alors des méthodes magiques, mais dans ce cas c'est phpunit qui ne sera pas content

Le problème c'est qu'en fait, personAddress est un "trait" de Address. Les aspects n'étant pas vraiment disponibles en PHP 5.3, nous avions opté pour l'héritage, ce qui permet d'avoir les méthodes d'accès de Address dans personAddress aussi.

Sauf que l'héritage que Doctrine2 propose est une horreur du point de vu des bonnes pratiques dans la conception des bases de données; elle cause littéralement des duplicatas de données !

J'ai d'ailleurs posté sur la mailing list de Doctrine, de même qu'une question sur stackoverflow, mais il semble vraiment que ce que je cherche à faire ne soit pas supporté, puisque toutes les alternatives proposés démontre des failles majeurs au niveau des bonnes pratiques -- soit du coté de PHP, soit du coté de la base de données.

Au final peut-être que les ORM sont d'avantage utile pour les petits projets sans complexité au niveau de la gestion des données que pour les projets d'envergure réelle ?

[RapotOR]

De mon experience, les ORM sont effectivement limités pour les grosses applications. Il faut user de bidouille en bidouille. C'est de plus en plus l’idée du "je programme avec l'orm mais ne sais pas ce qu'il se passe en bdd".


Je comprends ton soucis du getAdress().
Il est effectivement possible de rajouter des getter/setter dans personAdress pour acceder plus simplement à Address.

Code :

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

1
2
3
4
5
 
public function getRoad()
{
   return $this->getAddress()->getRoad();
}

Ce n'est pas vraiment de la duplication de code.

[FMaz]

Je comprends ton soucis du getAdress().
Il est effectivement possible de rajouter des getter/setter dans personAdress pour acceder plus simplement à Address.

Code :

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

1
2
3
4
5
 
public function getRoad()
{
   return $this->getAddress()->getRoad();
}

Ce n'est pas vraiment de la duplication de code.

Si j'ai 10 types d'address, dans les 10 objets ( personalAddress, businessAddres, organisationAddress, etc...) je vais devoir avoir l'ensemble des méthodes proxy.

As moins que je les place dans un objet abstrait, et que mes type d'adresses héritent de cet objet. Mais effectivement, on tombe dans le monde de la bidouille :p

Code :

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

1
2
3
4
5
6
7
8
9
10
 
abstract class addressProxy{
    public function getRoad()
   {
       return $this->address->getRoad();
   }
}
class personalAddress extends addressProxy{
     protected $address; //Méthodes d'accès fournis par addressProxy.
}

Bref, on commence à être pas mal hors-sujet, mais tout ceci pour dire que l'ORM est beaucoup moins génial qu'il ne semble l'être lorsqu'on nous le présente.

[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é

[Michel Rotta]

Vu le nombre de type de données différentes il est peut-être possible d'envisager des outils différents que l'ORM pur et dur...

Il existe les bases de données non structurées, tel mongo, qui permettent de bien gérer ce type de cas, au prix d'une remise en cause importante des habitudes de développement.

Si non il existe aussi un bundle, metastaz, qui permet de simuler des objets dynamique dans une base structurée. Ceci déstructure le modèle objet, mais permet de répondre plus simplement à ton type de cas.

Dans ces deux cas, il peut aussi être intéraissant de passer par un moteur d'indexation externe (SolR ou ElasticShearch).

[macksoft]

j'ai commencer utiliser symfony 2 il y'a de cela 2 mois.Mais j'ai beaucoup aimé .Sa combinaison avec le moteur de template twig lui donne une force énorme .la documentation est bien faite vous trouverez sur http://symfony.com/