Symfony

[Hasgarys]

- Ceci n'est pas un troll ; juste un retour d'expérience.
- Ne s'adresse pas aux débutants

Je récapitule rapidement la situation.

ça fait 4 mois que la société pour laquelle je travaille est en mission au ministère de l'éducation pour développer/déployer une application php basé sur le framework symfony (le framework php hype du moment)

Petite particularité, la sgbd est oracle.

Nous n'avons pas réussi a faire tourner l'orm Doctrine (pourtant bien plus performant que Propel) ; donc rabattu sur la couche native Propel ; super générateur de code... (Les designs patterns ils ne doivent pas bien connaitre vu les milliers de lignes de code générées)

Configuration de la connection à la base de données plus que compliquée, les fichiers yml (pourquoi pas un bon vieux xml ? faut arréter de pomper ruby on rails surtout quand on le fait mal) n'étais pas pris en compte et le "magique" système d'autoload des classes complétement buggué sur la version que l'on avait.

Les helpers html buggués, rien que pour faire des liens et des formulaires il a fallu hacker les sources de symfony car du passage de l'environnement de dev à celui de test, les liens ont été crashés - pour cause de "smart url" pas smart du tout. (exemple : "http://uneAdresse", "http://uneAdresse/" "http://uneAdresse/index" et "http://uneAdresse/index.php" pour symfony c'est trois trucs qui n'ont rien à voir.

Installation de symfony avec des options d'url rewriting non documentées planquées dans un coin qui nous ont fait perdre pas mal de temps.

Problème avec l'ajax sur le multi-requêtes.(En gros une seule requête ajax est traitée à la fois, la seconde doit attendre que la première soit terminée) - pas trouvé la raison ; probablement dans l'architecture de la couche contrôleur.

Jointures quasiment impossibles à gérer proprement avec l'orm, il a falllu passer directement par des appels propels pour ne pas faire de boucle de requêtes imbriquées.

Modèle MVC étrange, dans la couche controleur les attributs de type $this->uneVariable deviennent des variables directement accessibles dans la vue. ($this->uneVariable devient dans la vue $uneVariable ; c'est propre...)

Documentation hype mais inutilisable dans un cadre pro (entendre par là mise en place et apprentissage rapide) ; documentation de l'api nulle.

Nécessité de passer par la ligne de commande pour appeler des scripts php d'install et de vidage de cache. (Purement masturbatoire faire un "php script.php") Et donc impossibilité en l'état d'installer symfony sur un système où l'on n'a pas des droits de root (ou assimilés).

Support des équipes de symfony inexistant (canaux irc, forums etc)

Alors probablement qu'en y passant beaucoup de temps on finit par gagner du temps (il faut vraiment en passer beaucoup pour commencer a amortir le temps d'apprentissage/investigations)

Une "internationnalisation" plus qu'incomplête ; nous n'avons pas réussi a faire afficher le widget calendrier au format français et l'admin générator dont ils sont si fier, impossible de trouver de la doc pour convertir tous les labels en français.
//----

Quelques questions existentielles quant à la philosophie de ce framework

Pourquoi des fichiers de config en yml (sachant que ses derniers sont parsé pour devenir de bêtes define php) (a ma connaissance php5 gère nativement xml ;pas yml)

Pourquoi Propel alors que
PDO gère l'abstraction de façon native ; (Doctrine étant une surcouche de PDO) ; et sans utiliser PDO, pourquoi pas adodb très largement répendu. (N'est pas un orm, mais juste une couche d'abstraction certes)

Je n'ai pas la motivation pour énumérer tous les points étranges ou bloquant de ce framework ; mais et même si celà est subjectif ; je ne conseille à personne ce framework.

(j'avoue je sature un peu de ce projet/symfony)

[Sephi-Chan]

Et bien, ça ne donne pas envie de s'y mettre...


Sephi-Chan

[Plume]

Ceci étant dit, y a quelque chose de bien ? ^^

En tous cas, merci de partager ton expérience, ça m'évitera de me lancer. J'aurais été totalement largué :S

[naholyr]

Étrange, j'ai commencé avec la 1.0.6, le site en prod tourne sur un Apache / SQL Server (donc pas l'idéal) et je n'ai jamais eu le moindre des problèmes que tu cites.
Vous avez du commencé avec une version ancienne (genre 0.8), et dans ce cas je n'aurais qu'une chose à dire : quand on est une société sérieuse on ne démarre pas un projet avec un framework en phase beta (voire alpha).

Je pense que tu n'as simplement pas fourni les efforts nécessaires pour passer au-delà des problèmes rencontrés, quand on utilise un framework on ne va pas hacker les sources au moindre problème qu'on considère insolvable, on commencer par relire et relire la doc, parcourir l'API, etc… Les problèmes de fichiers de conf non reconnus, c'est typique du non vidage de cache, ça doit être vu à peu près dans chaque chapitre de la doc.

Le choix de Propel est discutable, mais en l'occurrence dans sa prochaine version il se base sur PDO ce qui simplifiera pas mal de choses. C'est déjà utilisable avec Symfony, vous qui n'avez pas peur des librairies en beta vous devriez essayer

Pourquoi le YaML ? Je dirais pourquoi le XML...
Pourquoi écrire

Code :

<?xml bla bla bla>
<config>
  <app>
    <variable name="coco" value="chanel" />
  </app>
</config>

quand on peut écrire

Code :

app:
  coco: chanel

?


Entrer dans un framework, quel qu'il soit (Copix, Prado, Symfony, PEAR et Zend étant à part car ce sont des librairies et pas vraiment des framework), c'est entrer dans l'esprit de son fonctionnement. Ne pas réussir à changer un minimum sa vision du développement d'un projet c'est d'office échouer dans l'apprentissage de ce framework.

[Hasgarys]

(xml parce que php5 parse nativement le xml)
(la distrib a été imposée par le client)
(La couche pdo s'appelle Dotrine comme sité dans le premier message http://doctrine.pengus.net/)
("symphony cc" nous connaissons ; j'ai d'ailleurs cité le problème de la ligne de commande (après il y a le dossier cache vidable "à la main")

Disons que nous n'avons pas eu de chance; car dans le cas contraire à la lecture du dernier message ; nous (je) serions des "comiques" ; ce qui pourrait être disons "intellectuellement dérangeant".

Pour les points positifs ; étant donnée que tout passe par des surchouches, pas de soucis de magic quotes/injectionSql/xss/uploadFichier à prioris.

Abstraction du sgbd (Librairie Créole)
Pattern active record (Librairie Propel/Doctrine) qui accélère le développement sql, (mis de coté l'aspect jointures complexes)
Modèle mvc de base (même si l'implémentation me laisse perplexe)
Gain de temps avec l'admin générator (si vous faites de la "bête" administration de tables isolées)

Donc comme dit dans le premier post ; si vous avez beaucoup de temps à consacrer pour l'apprentissage (je dirais plus exploration à la vue de la doc) et que les projets sont plutôt pas complexes (au niveau du modèle) vous devriez au bout d'un moment gagner du temps.

Ceci dit pour moi Symfony se résume dans la phrase trouvée dans la doc/livre de ce dernier
http://www.symfony-project.com/book/1_0/...ony-s-Code


"Constants
Surprisingly, you will find very few constants in symfony. This is because constants have a major drawback in PHP: you can't change their value once they are defined."



:good:

[naholyr]

Avant toute chose, même si ce message peut te sembler blessant, je te demanderais de le prendre plus comme une invitation à demander de l'aide que comme une critique destructive. J'espère que tu insisteras parce que ça en vaut la peine.

(xml parce que php5 parse nativement le xml)

Etant donné que la config n'a pas besoin d'être parsée tous les 4 matins, ça ne fait aucune différence. Le confort de l'utilisateur passe avant, et l'expérience Rails a montré la popularité du YaML. Forcément ça ne convient pas à tous, mais ça convient à une écrasante majorité.

(la distrib a été imposée par le client)

Il avait tort, c'était probablement trop tôt. Mais bon on n'a pas toujours le choix, et parfois le client rejette les conseils de ce type.

(La couche pdo s'appelle Dotrine comme sité dans le premier message http://doctrine.pengus.net/)

Non je te parle bien de Propel 1.3. Actuellement Propel est embarqué dans sa version 1.2, et la 1.3 est bien plus performante (les benchs la montrent même plus performante que Doctrine) et repose sur les PDO. Elle ne sera pas embarqué dans Symfony 1.0.x ni Symfony 1.1.x pour cause de rupture trop brutale avec les pré-requis (PHP 5.2 requis), mais est déjà disponible sous forme de plugin (sfPropel13Plugin) et marche fort bien (quelques patchs à appliquer sur les plugins tiers existants, mais je n'ai encore pas croisé un patch de plus de 20 lignes à ce sujet ).

("symphony cc" nous connaissons ; j'ai d'ailleurs cité le problème de la ligne de commande (après il y a le dossier cache vidable "à la main")

Je vais y répondre, parce que j'ai détecté quelques incompréhensions du système.

donc rabattu sur la couche native Propel ; super générateur de code... (Les designs patterns ils ne doivent pas bien connaitre vu les milliers de lignes de code générées)

N'hésite pas à proposer mieux, il y a déjà un bon paquet de choses qui sont présente dans BaseObject, appliquer des Design Pattern ici rendrait certes le code des classes Base* moins lourd, mais ça ajouterait encore une couche dont on peut en l'occurrence se passer. Les perfs de Propel (1.2) sont déjà assez mauvaises comme ça... De toute façon l'idée c'est de ne pas avoir à mettre le nez dans le code des classes de /lib/model/om/ mais de simplement ajouter les méthodes que l'on souhaite dans /lib/model/.

Configuration de la connection à la base de données plus que compliquée

mysql://username:password@server/database c'est si compliqué ?
On démarre un projet en 2 minutes : création du squelette, édition du fichier propel.ini (url ci-dessus à placer dans propel.database.url = ...), du fichier databases.yml (même style), et c'est parti...

le "magique" système d'autoload des classes complétement buggué sur la version que l'on avait.

Avoir le numéro de version aiderait. Mais tout ce qui concerne l'autoloader n'a plus de gros bugs depuis... pfiou. Sauf si on ne vide pas le cache, auquel cas toute modification dans la structure des fichiers (déplacement, suppression, nouveau fichier) amènera des erreurs car il n'ira pas chercher les fichiers au bon endroit : l'autoload est configuré au premier lancement s'il n'y a pas de cache (il génère un tableau associatif className => fileName), et n'est plus jamais recalculé après, il suffit de vider le cache.

Les helpers html buggués, rien que pour faire des liens et des formulaires il a fallu hacker les sources de symfony car du passage de l'environnement de dev à celui de test, les liens ont été crashés - pour cause de "smart url" pas smart du tout. (exemple : "http://uneAdresse", "http://uneAdresse/" "http://uneAdresse/index" et "http://uneAdresse/index.php" pour symfony c'est trois trucs qui n'ont rien à voir.

C'est le rewrite_url qui fait ça, en environnement de dev http://unAdresse/index ça va utiliser la route /index si elle existe, et sinon pointe vers le module index/index (module index explicitement demandé, action index par défaut). http://uneAdresse, http://uneAdresse/, et http://uneAdresse/index.php doivent eux pointer sur la route par défaut (par défaut default/default, sinon c'est simplement la route @homepage que l'on peut configurer toujours dans le système de routage).

Installation de symfony avec des options d'url rewriting non documentées planquées dans un coin qui nous ont fait perdre pas mal de temps.

C'est bien documenté dans la partie concernant l'aspect des URLs. En revanche j'ai détecté récemment quelques bugs dans la traduction française (ça c'est vraiment nul par contre, c'est un comble pour un projet d'initiative française !!) sur ce chapitre.
La directive Apache URL_Rewriting n'est pas documentée, ils fournissent un .htaccess qui marche "out-of-the-box" pour 99% des besoins, si on veut le customiser c'est vers Apache qu'il faut se tourner.

Problème avec l'ajax sur le multi-requêtes.(En gros une seule requête ajax est traitée à la fois, la seconde doit attendre que la première soit terminée) - pas trouvé la raison ; probablement dans l'architecture de la couche contrôleur.

Non c'est simplement les helpers qui génèrent des appels synchrones. Il faut juste ajouter l'option "asynchronuous=true"...

Jointures quasiment impossibles à gérer proprement avec l'orm, il a falllu passer directement par des appels propels pour ne pas faire de boucle de requêtes imbriquées.

L'ORM c'est Propel, donc "des appels propels" c'est pas "avec l'orm" ? faute de frappe ? tu voulais sans doute dire "des appels Creole" pour faire les requête directement.
C'est l'un des vrais défauts pour les débutants (dans l'utilisation d'un orm) : on a l'habitude de faire des requêtes ultra-complexes qu'on ne peut plus faire ici "de base". Mais c'est normal, "de base" il ne gère que les cas... "de base" :lol: donc une jointure sur 3 tables par exemple passera parfois par une requête à la main (on reste database-independant puisqu'on est en fait toujours dans le contexte de Creole), qui sera judicieusement placée dans une classe *Peer. En revanche les relations 1-n (2 tables), 1-1 (2 tables) et n-n (3 tables) sont gérées nativement. Un niveau de relation supplémentaire nécessite forcément une adaptation.
On ne peut pas décemment lui demander de traiter tous les cas possibles, mais je t'accord que quand on doit faire des requêtes complexes, ça peut être pénible. Perso sur le projet que j'ai en prod j'ai une requête avec jointure de 4 tables et un WHERE avec des AND imbriqués dans des OR, ça devient vite affreusement verbeux, mais ça reste à peu près relisible, encore que pour le coup j'eus préféré un bon vieux SELECT que j'aurais probablement mis 5 fois moins de temps à écrire, mais on ne peut pas gagner du temps à tous les étages.

Modèle MVC étrange, dans la couche controleur les attributs de type $this->uneVariable deviennent des variables directement accessibles dans la vue. ($this->uneVariable devient dans la vue $uneVariable ; c'est propre...)

Parce que tu n'as pas compris leur implémentation.
Le contrôleur, c'est le point d'entrée (bootstrap), c'est tout simplement index.php.
Le modèle c'est ce qu'on trouve dans /lib/model/.
La vue c'est ce qu'on trouve dans */templates/.
Ce dont tu parles, ce sont les actions, qui sont le joint logique entre le contrôleur et la vue. Dans toutes les implémentations du modèle MVC que j'ai croisé (Prado, Zend, Symfony et Copix), ça marche comme ça.

Le $this->variable, c'est un heureux raccourci. Si tu ne veux pas en bénéficier le plus simple c'est de séparer les choses :
- Les attributs de ton objet sfAction sont déclarés bien évidemment, et ne passent donc pas par __set() quand tu appeles $this->variable, et ne seront donc pas passés à la vue.
- Les attributs inexistants définis par $this->variable passent par __set() et sont envoyés à la vue par $this->varHolder->setByRef($key, $value). Tu peux donc simplement passer explicitement par là.

Documentation hype mais inutilisable dans un cadre pro (entendre par là mise en place et apprentissage rapide) ; documentation de l'api nulle.

Avez-vous seulement essayé de la généré avec phpDocumentor par curiosité la doc de l'API ? Parce que si je prends une classe au hasard on ne peut pas dire que l'API manque de documentation... La page "API" de leur site oui, il n'y a que l'essentiel.
La documentation du site est assez complexe à prendre en main je suis d'accord, c'est adapté à un tuto, pas vraiment à un support de dév par la suite. Il existe de nombreuses cheatsheets sur les newsgroups qui sont d'excellente facture.
Enfin tu parles dans le cadre pro d'apprentissage rapide : l'apprentissage rapide d'un outil d'une telle ampleur ça n'existe pas, il faut au moins 2 ou 3 semaines et un projet factice pour se faire les dents. C'est vrai avec tous les outils de cette importance, ce n'est pas parce qu'on est pro qu'on est au-delà des normes humaines :lol: il faut aussi accepter ça.

Nécessité de passer par la ligne de commande pour appeler des scripts php d'install et de vidage de cache. (Purement masturbatoire faire un "php script.php") Et donc impossibilité en l'état d'installer symfony sur un système où l'on n'a pas des droits de root (ou assimilés).

Les taches pake sont extrèmement pratiques, et ne nécessitent nullement d'avoir les droits root mais un simple accès shell (c'est ça que tu appelles "assimilés" ? C'est carrément pas pareil pourtant). Et si ça n'est pas possible, on peut aussi installer le plugin sfControlPanel qui ajoute une interface de gestion et qui (pour peu qu'on ait droit à exec()) exécute ces commandes dans un clicodrome.

Support des équipes de symfony inexistant (canaux irc, forums etc)

J'avoue ne pas pouvoir répondre grand-chose, je n'ai jamais eu besoin d'y avoir recours, le seul contact que j'ai eu c'est lorsque j'ai contribué au plugin sfSimpleForum, je dois dire que la réactivité de l'auteur du plugin me laisse perplexe (toujours pas de réponse...).
Ce qui me fit toujours rire c'est que dans 99% des topics du forum il n'y a que des français qui parlent entre eux... en anglais :lol:

Une "internationnalisation" plus qu'incomplête ; nous n'avons pas réussi a faire afficher le widget calendrier au format français et l'admin générator dont ils sont si fier, impossible de trouver de la doc pour convertir tous les labels en français.

Les labels sont renommables dans generator.yml et ça c'est documenté. Ensuite tous ces labels passent par __() et sont donc traduisibles dans le fichier de locales (format XLIFF par défaut, voir le chapitre i18n).

Pourquoi Propel alors que
PDO gère l'abstraction de façon native ; (Doctrine étant une surcouche de PDO) ; et sans utiliser PDO, pourquoi pas adodb très largement répendu. (N'est pas un orm, mais juste une couche d'abstraction certes)

Beaucoup se demandent justement "pourquoi pas Doctrine" ce qui a amené la création du plugin sfDoctrinePlugin. je ne l'ai jamais utilisé donc je ne peux pas dire grand-chose sur l'expérience que vous en avez eu...

(j'avoue je sature un peu de ce projet/symfony)

Réaction épidermique à un effet de mode, c'est bien normal. Dis-toi que moi je sature des iPod par-ci iPod par-là :lol:


J'espère que cette mauvaise expérience vous fera prendre conscience que l'échec est du à une mauvaise approche et pas au framework lui-même, et à réessayer plus tard. Parce que ça vaut vraiment le détour, mais c'est un esprit à assimiler.