J'aimerais vous demander vos avis pour Symfony2 qui est disponible en beta ici : http://symfony.com et qui est actuellement disponible depuis mars 2011 en Preview Release 7.
Quick Tour : ici The Book : ici Symfony API : ici Symfony2 Bundles : ici
N'oubliez pas de préciser si vous êtes utilisateur de Symfony 1.x (ou de tout autre framework mais sans créer de troll).
Tout ceci semble vraiment intéressant, notamment l'intégration de Twig qui est un moteur de template très prometteur !
Merci !
P.S.: n'hésitez pas à partager vos bons liens Symfony2, je les rapporterai ici !
P.P.S.: il faut écrire Symfony2 (pas d'espace avant le 2)
Une erreur dans cette actualité ? Signalez-le nous !
C'est une excellente question à la quel je n'ai pas de bonne réponse.
Tu as presque deux framework différents.
Tous dépend de pourquoi tu veux t'y mettre.
Si tu as un projet qui doit être terminé dans les 3 mois, la 1 est pour toi.
Si tu as des bases légères en PHP et peu de notion en objet, namespace, ... la 1 est pour toi.
Si tu désire te former pour l'avenir, la 2 est la bonne
Si ton projet ne doit pas voir le jour avant 6 mois à 1 an et devra durer éternellement, la 2 est la bonne (quoique, éternellement, c'est peut plutôt l'asile qu'il faut viser )
Pour moi symfony2 est du tout bon, il reprend plein de principe déjà présent dans de nombreux framework ( peut importe le langage ). Alors oui bien sur il y a beaucoup de changement, normal ils sont repartis de zero. Il est moins complet bien sur, sur des fonctionnalité que j'estime annexe, que symfony 1.4 et ça c'est normal. Avec php5.3 et l'arrivée des namespaces symfony2 a une architecture beaucoup plus cohérente, pour moi symfony2 n'est pas qu'un framework mvc, mais permet d'avoir une architecture beaucoup plus complexe plus facilement qu'avec la mouture précédente. symfony est donc beaucoup plus modulable qu'auparavant. Je l'ai déjà adopté =).
Je me permet d'ajouter mon petit grain de sel au bout de 2 années de Symfony ..
Symfony peut autant apporter des choses sympatiques ( routes / annotations / mapping relationnel dans les formulaires )
autant son usage peut surcomplexifier de nombreuses choses et devenir rapidement une "cacophonie" de "bundles".
Je me souviens que la prise en main ne fut pas évidente du tout, néccessita bien 2 mois avant d'être "pleinement opérationnel" ..
Je rejoins tout à fait l'avis de SurferIX sur le vol de cerveaux : j'ai vu de nombreuses personnes ne savant pas faire à la base, en php natif ce que Symfony fait nativement ( formulaires, token crsf, entités, requêtes sql natives ) et cela est fort dommage, car il n'y a vraiment rien de sorcier, et c'est là que débute la grande mystification .. que les gens ne jurent que par leurs bundles favoris sans en comprendre le fonctionnement interne.
Je ne comprends pas non plus l'emballement "auto-promo" autour de Symfony, du moins de part la part des consultant Sensio et affiliés, sur Lyon et Paris, principalement. Les plus grands fans de symfony sont en général les personnes les plus éloignées du language natif php, ceux qui ne peuvent pas intervenir sur des php " Homemade ", tout sauf des profils tout-terrain.
J'ai vu des personnes découvrir le front controller avec symfony, d'autres personnes pouvant uniquement effectuer des requêtes par doctrine .. avec un certain fanatisme au point de dire " le reste, ce qui m'est inconnu, ne vaut rien " .. ce qui est fort dommage ..
Il est probable que quelqu'un qui s'intéresse de près à ton application finisse par découvrir que tu l'as développée en Symfony 2.
De la a imaginer que cette connaissance va lui offrir des axes d'attaques, je n'en suis pas aussi sur. En effet, Symfony a toujours mit la sécurité à la première place, elle permet facilement de sécuriser les saisies par CRSF, par la validation systématique des paramètres en POST comme en GET, par l’échappement systématique des données affichées ainsi que des données envoyées vers la base de données, par le déport des fichiers PHP hors de l’arborescence accessible, par l'introduction au seins même du contrôleur d'un système de gestion des droits très élaboré qui va bien au delà de la simple authentification.
Et je pense en avoir oublié.
Donc, je suis plus à l'aise avec un site moyennement bien développé avec Symfony 2 (ou 1.4) qu'avec un site bien développé en PHP 4 (ou 5 en procédural) et avec un fichier accédé par action. Même si sur la première page du site il est écris "développé sous Symfony 2".
J'ai travaillé sous symfony premier du nom pendant deux ans, et j'ai maintenant deux ans de pratique sur le deuxième.
Avec le recul je me rends compte sur pas mal de points que ces deux versions, c'est le jour et la nuit.
symfony 1.x était pour moi beaucoup moins permissif et par conséquent, plus adapté à l'utilisation pour les débutants. Ça avait pour conséquence de laisser moins de place à certaines fautes de conception pour un développeur junior. Pour avoir basculé d'une utilisation de ZF1 à SF1, j'ai trouvé que symfony était plus simple à prendre en main. En revanche, c'était au prix de beaucoup de "magie" interne qui compliquait parfois le debug.
Symfony2 laisse un plus libre choix au développeur et donc s'adresse à mon avis à un public déjà un peu plus averti, au risque de voir apparaitre des raccourcis un peu douteux. Mais paradoxalement, je trouve qu'il permet également de s'intéresser facilement à ces fameuses "bonnes pratiques" en s'appuyant directement sur le code du framework, plus accessible que celui du premier. Le concept le plus important à mon sens étant l'injection de dépendances qui permet de facilement se rendre compte du couplage entre les différentes classes que l'on crée, et donc de la souplesse et la maintenabilité du code.
@gototog : je travaille maintenant depuis 6 mois sur un projet ou les contrôleurs ne manipulent que des services perso. Pas de doctrine dans les contrôleurs, pas de validation de formulaire dans les contrôleurs. De manière à les alléger le plus possible. Le contrôleur reçoit une requête et renvoie une réponse, et entre les deux : des appels à des méthodes de service, des redirections, et des exceptions, pas plus.
L'avantage de manipuler beaucoup de services est justement de se rendre compte rapidement, ou est-ce qu'on a besoin de factoriser, repenser, réorganiser l'architecture. Je trie mes services de cette manière :
Converter (permet d'instancier un objet avec toutes les jointures que l'on veut lorsqu'on passe par exemple son id dans une route)
EventSubscriber (traitement des évènements postSave, preDelete, postCustomMethod etc.)
FormHandler (traitement des formulaires)
Manager (code métier, persistance des objets etc.)
plus quelques uns que j'ai du oublier en route...
Niveau bonnes pratiques, je pense que l'idéal encore une fois est de s'intéresser à tout ce que le framework propose, essayer de l'utiliser et voir combien de : lignes de codes|requêtes|mémoire|temps d'exécution (rayez les mentions inutiles) ça te fait gagner. Une utilisation basique du framework sur des projets tutos bateaux comme on en voit fleurir partout sur le net se résume à :
installer ton environnement de dev
créer ton modèle
créer tes contrôleurs et tes routes
créer des services
créer deux formulaires et demi pour la forme
Avec ça difficile de trouver des cas d'optimisation et le besoin de bonnes pratiques.
Personnellement je travaille beaucoup avec les Event et EventSubscriber. Je trouve que c'est un concept qui est assez peu abordé et pourtant qui est très utile dans de nombreux cas et limite les oublis et/ou effets de bord.
Les autres bonnes pratiques, ce sont celles de la POO tout simplement. Je ne compte plus les développeurs qui font de l'objet (que ce soit du PHP, Java ou quoique ce soit d'autre), parfois travaillent avec un framework, mais qui n'ont pas assimilé ne serait-ce que deux ou trois DesignPattern. Dans la théorie, ils peuvent t'expliquer comment fonctionne un Decorator ou un Factory, mais n'ont pas le réflexe de se dire : "Tiens, je suis confronté à une problématique qui doit être récurrente en POO. N'y aurait-il pas un DesignPattern qui pourrait résoudre mon problème de la manière la plus propre possible ?".
Pour finir, une chose est sûre, c'est qu'après avoir travaillé avec un framework comme SF2, on a énormément de mal à revenir sur du développement from scratch (qu'on retrouve de moins en moins...et c'est tant mieux).
moi j'utilise FosUserBundle, simple et pratique à utiliser.
il existe des bundles de pagination
peut être tu ne fais pas de bonne recherche
Comme tout Symfony : utiliser le travail des autres... en priant que ce dernier soit bon.
Lis ma question ici : fosuserbundle-what-is-the-point.
Peut-être qu'il est censé faire le café et massage de pieds, mais concrètement, à part se limiter à faire des formulaires d'inscription + validation, il ne fait rien. 50 lignes de codes à écrire à la main en Php. Et s'il vous plaît, PUTAIN, le CRSF c'est DEUX lignes de codes, DEUX. Arrêtez de croire qu'il vous sauve la vie en vantant des choses qui prennent DEUX lignes de code en Php pur !
J'avais besoin de 2 types de profiles : étudiant et professeur. Bah après 3 heures d'install, config partout, fichier YAML à droite, fichier YAML à gauche, conclusion : il ne fonctionne pas comme ça, il n'est pas prévu ainsi, il faut rajouter une autre couche à la surcouche (= plugin) de la surcouche (= symfony) de Php. Si on en veut plusieurs, il va vous falloir installer un bundle supplémentaire : le PUGXMultiUserBundle.
La difficulté avec les Symfony addicts est qu'ils sont, pour la plupart, tombés amoureux... car c'est leur premier amour. Comme dans la vraie vie : le premier amour est toujours le plus beau, le plus fort, le plus émouvant, et rien ne peut être mieux. Une fois qu'on découvre d'autres choses ailleurs, c'est la rupture, toutes les étapes réelles de l'amour : d'abord la haine, la rancune : on en veut à son ex, puis quelque temps après on prend du recul : tout n'est pas tout blanc tout n'est pas tout noir, c'est aussi un peu de notre faute...
Symfony est tellement complexe qu’il faut absolument avoir un débogueur intégré tel que xdebug et pouvoir faire du pas à pas dans un environnement tel que PhpStorm qui donne la possibilité de suivre tout, avec la pile d’appel. Pour développer un site Web simple, Symfony est si complexe qu’il faut obligatoirement pouvoir faire du pas à pas dès qu'on sort des sentiers battus. Ce sont des experts Symfony qui me l’ont expliqué. Sur le coup j’ai sincèrement (honnêtement, ce n’est pas ironique, c’est véridique) cru que c’était une blague. Php est tellement simple et fluide quand il est bien développé que je n’ai jamais eu à utiliser de débogueur pas à pas en plus de dix ans !
J'ai écrit pas mal de choses sur Symfony à l'époque où il s'était si bien vendu à mes yeux que je pensais que c'était un bon framework. Tout est là.
Bref, j'ai pratiqué : YAF, Phalcon, Symfony2 (j'ai fait 2 sites professionnels avec, je sais de quoi je parle donc), mon propre framework (mon mémoire d'ingénieur est basé là dessus, j'ai eu mention bien, là aussi je sais de quoi je parle) et encore quelques autres (Pélican, framework maison de Business et Décision / BNPParibas), YII Framework, CakePhp etc, et actuellement Django.
Mon conseil de "vieux" :
- Symfony prône de bonnes pratiques, suivez les ! PSR0, 1 et 2 sont excellentes !
- Le code source de Symfony est très bien, regardez-le, inspirez vous en !
A partir de là : donnez vous un objectif simple de site "simple" : exemple : un site de questions/réponses avec utilisateurs enregistrés.
Essayez les meilleurs frameworks du moment (ou que je conseillerais) : Symfony2, YII framework, YAF, FuelPhp, codeigniter.
De là, consacrez vous une soirée complète par framework. A la fin de la soirée, faites votre conclusion : documentation ? clarté ? déboguage ? multilangue ? vitesse de développement ? vitesse d'exécution ? facilité d'installation ?
Bref, pour l'instant, Django éclate dans tous les sens du terme tous les frameworks que j'ai testés en Php. D'ailleurs pour apprendre le MVC avancé, je donne un site Web basique à faire en Django, et une fois qu'il est fait, je demande à ce qu'ils refassent le même en Silex, puis en Symfony (ici aussi, en suivant tous les slides et en travaillant ensemble). Je les avertis avant : il faut qu'ils prévoient au minimum 3 fois plus de temps pour développer en Symfony ce qu'ils ont fait en Django (deux années avec plus de 100 étudiants : les statistiques parlent d'elles-même !). Je ne vais pas dire ce qu'en pensent les étudiants ici, car on s'éloignerait du sujet, mais croyez moi, ils ne chercheront pas de Symfony dans le monde professionnel...
Le truc qui me gêne le plus dans Symfony est très bien expliqué ici, je cite : l’infantilisation des développeurs que Symfony élève au rang de philosophie. Cela devient toujours problématique dès qu'il faut entrer dans le code.
Comme toujours, le vrai problème c'est que certains sont des développeurs 100% Symfony (ou 100% Laravel, qui est le champion de ce genre) et pas développeur PHP capable de passer de Symfony à Zend à Laravel à from scratch. On n'apprends pas à programmer avec un framework, on utilise un framework quand on sait programmer et qu'on sait déterminer quel framework (voire pas de framework du tout) est le meilleur outil pour le job du jour.
On peut même étendre ça aux langages. Même pour les applications web, Il y a des choses pour lesquelles PHP est adapté, d'autres que python fait très bien, et d'autres (nécessitant une excellente performance) Java. Rien n'empêche de faire une partie du code en Java, en node.js ou autre (sauf si on a la malchance d'avoir un serveur mutualisé, bien évidemment) et de faire dialoguer les langages (avec des sockets, un API rest etc...). On utilise quotidiennement plusieurs types de stockage de données (SQL, memcached, redis...) parce que chacun a des avantages uniques, pourquoi ne pas le faire pour les langages?
Le problème c'est que beaucoup ont une mentalité de secte: nous on a le seul vrai langage et les autres c'est de la m... Soyons plus pragmatiques!
Avec un peu de recul il y a des choses avec lesquelles je suis d'accord et d'autres pas des deux côtés.
Symfony a le gros inconvénient, mais ce n'est nouveau pour personne, d'être difficile d'accès. L'apprentissage est long et le passage de la version 1 à la 2 a été catastrophique car le framework n'avait plus rien à voir.
Sensio ne s'en est jamais caché et ils ont appris de leurs erreurs avec un passage à la version 3 qui se veut plus simple.
Personnellement je n'ai jamais utilisé le FOSUserBundle, mais je ne comprends pas vraiment son statut d'incontournable car une gestion user correcte et sans trop de difficulté est tout à fait réalisable sans.
La partie ORM maintenant : je pense qu'on enfonce des portes ouvertes en disant que du bon vieux SQL pur est plus performant (sous réserve bien sûr qu'on ait quelques notions dans l'optimisation des requêtes). Mais le but d'un ORM (au sens large, pas forcément Doctrine) n'est pas là. Moi je suis content de n'avoir aucune requête à écrire et me contenter d'un save() sur un objet ou un graphe d'objet de manière à cascader tous les enregistrements sur plusieurs entités et donc plusieurs tables. Et je sais qu'on peut cascader plein de choses coté BDD mais je n'en suis vraiment pas fan, déplacer de la logique dans la base est quelque chose qui m'ennuie beaucoup : j'aime que toute ma logique métier se retrouve au même endroit.
Mais on est bien d'accord, l'utilité de Doctrine (et de beaucoup d'ORM) s'arrête lorsqu'il faut faire des requêtes complexes ou très lourdes. Maintenant rien n'empêche d'utiliser les deux.
Symfony a aussi la particularité d'être un bulldozer, là aussi on est d'accord. C'est pour ça que j'ai demandé à SurferIX quel type de sujet il donnait à ses étudiants. Et en effet n'importe quel projet réalisable en 4h est un petit projet qui ne nécessite pas l'utilisation d'un mastodonte tel que Symfony. Silex serait alors plus adapté.
En revanche, moi qui travaille sur un projet de 100K loc, je pense que mon Silex ne ressemblerait plus à grand chose et que Symfony est plutôt un bon choix dans la mesure ou l'on arrive à faire évoluer le projet comme on le souhaite sans rencontrer de blocage architectural particulier.
Maintenant là ou je pense que tu as manqué quelques points SurferIX, c'est dans tes articles où tu décris ton retour d'expérience avec Symfony. Quand je vois que tu veux injecter des dépendances à ton entité, et que la création de service te semble être de trop je ne te rejoins plus. La force de Symfony2 c'est l'injection de dépendance, et quasiment toutes les classes d'un projet Symfony devraient être des services (sauf les entités). Et s'il faut faire des cabrioles pour injecter deux services à ton modèle, c'est parce que les classes de ton modèle ne sont pas supposées avoir de dépendances de ce genre. Tout passe par des services car tout peut être service dans Symfony.
Pour finir, on ne peut pas comparer l'écriture d'un programme basique from scratch ou presque en python, et l'utilisation d'un framework d'un autre language. Symfony n'est pas le bon outil pour réaliser une application en 4h de temps. Et ce n'est pas le bon outil pour un projet de 3 mois non plus si tu pars de zéro dans ton apprentissage car l'apprentissage triplera le temps de développement.
De la même manière je n'utiliserai pas un Magento pour faire un ecommerce de 4h, parce que c'est un tank pour tuer une mouche.
Par contre pour un projet avec une durée de vie longue dans un cadre professionnel, ou l'on aura besoin de s'assurer d'avoir toujours à disposition de la main d'oeuvre et des gens capables de reprendre le code plus facilement qu'un code "from scratch", utiliser un gros framework populaire possède ses avantages au delà de la technicité de l'outil lui même.
Pourquoi en France y a-t-il si peu de projets Python ou Rails ? Ce n'est pas parce que le language ou le framework est mauvais, bien au contraire, c'est parce que la main d'oeuvre manque.
En tout cas, point de vue intéressant avec la vision de quelqu'un qui n'en est pas à "son premier amour"
Ce qui fait vraiment plaisir dans ce sujet, c'est de voir apparaître plein de contributeur que l'on ne voit pas habituellement et qui mériterait largement de participer
Donc, il ne reste plus qu'a faire une salle spéciale pour Symfony 2 ?
!
)
Envoyé par dukoid
