Le découplage des classes du framework, l’arrivée du framework de formulaires et la nouvelle architecture REST ont vraiment donner un sens professionnel à Symfony. Certes la documentation entre la 1.1 et la 1.2 a été relativement absente mais elle tend à présent à s’étoffer et se mettre à jour.

Pour moi, Symfony n’est pas plus compliqué à apprendre qu’avant. Je dirai même que c’est plus facile aujourd’hui avec la 1.2 pour la simple et bonne raison qu’il y’a beaucoup moins de « magie » derrière les outils de Symfony. On sait exactement où se trouve chaque composant et comment il se comporte. En 1.0, l’utilisation abusive du YAML pour faire de la validation de formulaires était une aberration totale qui apportait son lot de magie et qui au final était une difficulté supplémentaire à gérer. C’est tellement plus simple d’écrire un message d’erreur dans la configuration d’un validateur d’un widget plutôt que dans un fichier YAML dans lequel il faut faire attention à l’échappement, l’indentation…

Toujours concernant la courbe d’apprentissage, je m’aperçois que de moins en moins de développeurs décrochent au début de l’apprentissage. Est-ce parce que c’est plus simple à apprendre ou bien parce qu’il y’a un côté fun, pro et sérieux à utiliser symfony ? Sincèrement je ne saurais répondre à cette question mais le constat est tel que je pousse de plus en plus de développeurs issus du monde PHP traditionnel à se tourner vers symfony, et ceux-ci arrivent à être opérationnels avec l’outil assez rapidement. Le tutoriel Jobeet et le form book actuel contribuent pour beaucoup à l’apprentissage de symfony et c’était exactement le cas à l’époque d’Askeet de la 1.0.

Pour moi, les développeurs qui décrochent de symfony rapidement et qui pensent que c’est trop compliqué, c’est qu’ils n’ont pas encore réussi à laisser de côté leur habitudes de codage en PHP traditionnel. Symfony est et reste du PHP à la base, donc tout ce qu’il est possible de faire en PHP est possible dans Symfony. Cependant, et c’est le but d’un framework, Symfony oblige de penser un projet et le code qui l’accompagne différemment. Pour y arriver et comprendre comment fonctionne la logique globale de symfony, il faut être capable de laisser de côté ses vieilles habitudes de codage en PHP et se mettre à penser MVC, OOP et bonnes pratiques.

Hugo.

Pourquoi ne pas choisir Zend ?
Il est tout aussi professionnel (plus ??)

La raison ? Et bien symfony permet de faire du RAD (Rapid application development) cependant plus la complexité augmente plus il devient difficile de vraiment penser au RAD.

Cependant, je crois que pas mal d’effort on été mis dans sf1.2 avec toute la doc (c’est fantastique !!) et les exemples, et jobeet …
et c’est une excellente chose.

Tellement excellente que j’ai peur de me faire dépasser dans ma connaissance de sf par des nouveaux venus qui travaillent avec la nouvelle doc alors que moi je suis plus occupé à développer(Avec mes connaissances actuelles) qu’à me documenter.

Mais bon, Vive sf
Pour ReTweeter qqn : Damn Symfony is so sexy :)

Depuis 1 an, symfony me permet d’aller beaucoup loin simplement avec quelques lignes de commandes et quelques fichiers conf avec le super systeme yaml+quelques plugins (sfGuard).

Rien qu’avec la doc et les tuto, on peut aller déjà très loin et facilement pour construire un site web avec une personnalisation qui répond à nos besoins.Ce que ne peut pas nous offir les autres systemes opensource (wordpress,DRUPAL,plegg,etc)

De plus, les bonnes pratiques MVC,AGILE,STORY BOARD etc sont toujours présentes pour autoformer un débutant dans le développement.
J’espère d’ailleurs que l’admin generator de symfony 1.3 intègrera du jquery facilement afin d’améliorer l’expérience utilisateur.J’ai pas eu le courage de me lancer ds sfYUI…

La tache la plus difficile est de savoir si on veut aller plus loin, cad lire la nouvelle doc sur les forms,propel ou/et doctrine, et se plonger dans l’api !

Pour répondre au titre de l’article, je trouve que symfony facilite déjà beaucoup la production de site web pour n’importe quel informaticien de base.
Bref, un must de l’opensource !

j’espère un nouveau livre pour la 1.3.

Sur ce je continue le tuto jobeet ;-

Ton problème vient peut être du fait que tu estimes que c’est ton intégrateur qui doit fabriquer le formulaire, hors symfony a estimé que c’était du ressort du développeur.

Personnellement j’estime que justement, le nouveau système de formulaire permet de conserver MVC.

De mon point de vue, Symfony 1.1 (et donc 1.2) est devenue trop compliquée… à cause de la framework interne des formulaires. Le reste étant resté identiquement difficile ;). La courbe d’apprentissage est très importante, et elle devient tout de suite abrupte.

Attention ! Je ne remets pas en cause l’utilité et la « puissance » de cette framework interne de formulaire… Une telle framework est tellement essentielle que j’en avais développé une perso pour Symfony 1.0.

Mais…

Vous verriez la tête de mon intégrateur web quand il est l’heure de mettre en page un formulaire. Je suis obligé d’être derrière lui pour lui dire où se trouve tel ou tel champs, de quel fichier XyzForm.class.php découle le $formulaire qu’il manipule et quels options ou attributs passer à l’infâme $this->widgetSchema['xyz'].

Pour quelqu’un qui n’est pas censé savoir faire du PHP (mais de l’HTML/CSS)… Dur!

Je rejoins aussi Loïc sur le point des fichiers de configuration… Dans 99% des cas, on se contente de faire widgetSchema->setLabel(‘x’,'y’),
widgetSchema->setHelp(‘a’,'b’) et validatorSchema['z'] = new sfValidatorLookInApiForName( array(/*options*/), array(/*messages*/));

Honnêtement, un fichier de configuration peut faire tout ça ! Et mon intégrateur n’aura plus peur de « casser » le code de ma classe XyzForm

Pour finir, je ne pense pas que la classe sfForm doive être responsable de son affichage… Pourquoi aller changer la valeur des labels dans la classe TrucForm ? Pourquoi dois-je choisir le « FormFormatterName » dans une classe PHP ? (ou dans l’action).

Imaginez un instant que la classe Article de votre modèle soit responsable de son affichage via un classe qui s’appelle : sfPropelModelFormatterTable. Une classe qui ne serait pas documentée. L’angoisse, non ?

Remarque, c’est super : dans le viewSuccess, on met juste un et voilà! C’est l’intégrateur qui va être content…

Bref ma conclusion -vous l’aurez compris – est la suivante : Nous avons perdu la conception MVC dans la framework des forms. Et c’est dommageable.

A bientôt,
Jug