Symfony

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