Discussion :

[dukoid]

le fait qu'il gère le CSRF alors que quand on sait coder, le CSRF c'est DEUX lignes de code. Mais comme tu ne sais pas développer, ou que tu n'as que très peu d'expérience, voire les deux, on sent bien que tu trouve ça fabuleux. J'ai bien envie de t'écrire tout ça en ARIAL 80 GRAS mais ça gâcherait ma réponse.

mais qu'est ce que je m’en fou de ton CRSF, je t'ai dis que le plus intéressant dans fosUSer c’était le pack (gestion de l'activation, nouveau mot passe, mot passe oublié.... tu fais le forcing sur ce point mais non.

tu caricatures lamentablement les utilisateurs de symfony, quand on a pas d'argument fort c'est ce qu'on fait en général.

C'est que tu n'as jamais poussé Symfony loin et que t'as toujours eu que des besoins à la "deux champs à faire et un login classique".

tu as lu ça dans ta boule de crystal, encore des suppositions pour te donner raison.

J'espère que tu sais qu'en écrivant cela : "on n'a pas besoin d'outil pour faire du pas à pas", tu réalise ce que tu dis ?
Au vu de tout ce que tu as écrit, j'espère de tout mon coeur que des personnes qui voudraient t'embaucher liront cette phrase, et que tu auras le culot de le dire à voix haute en face d'un leader technique cette même phrase, pour qu'il réussisse à convaincre son patron de ne jamais t'embaucher.

mais arrête de dire des conneries. xDebug c'est pourrie, c'est lent.. pour arriver au bugue faut 10min si ça ne plante pas non mais tu rigoles ????
il y a rien de mieux qu'un bon error_log .. c'est rapide, clair et ça bloque jamais.

Ah ces débutants... je te laisse avec ton premier amour en espérant sincèrement que le jour où tu réalise à quel point il y a mieux ailleurs ça te fasse d'autant plus mal. Tu ne mérite que cela.

oui bien sur, l'herbe est toujours plus verte ailleurs.




allez le geek de service, tu as toujours raison, tu es le plus beau, le plus intelligent...... je te souhaite bon vent.



Symfony

les qualités :
Twig : une merveille
les routes : super pratique et simple
les services : puissant, tout en objet.
mvc : un bon compromis.


les défauts :
doctrine (mais on peut s'en passer)
les formulaires complexes : un peu hardu à coder des formulaires complexes(formulaires imbriqués....)
l'apprentissage ( un peu plus long que les autres frameworks)

[DarckCrystale]

tu as lu ça dans ta boule de crystal, encore des suppositions pour te donner raison.

Plutôt que de répondre avec de la mauvaise foi, on pourrait savoir comment sous Symfony2 tu vas gérer des utilisateurs avec des droits ? Un exemple simple, juste un site accessible par enseignants et élèves, les élèves peuvent consulter, les enseignants peuvent insérer des données.

Symfony

les qualités :
Twig : une merveille
les routes : super pratique et simple
les services : puissant, tout en objet.
mvc : un bon compromis.

TWIG est disponible aussi si on fait du home made. J'envisage de l'utiliser, c'est en discussion avec les gens avec qui je bosse.
Les services, ça existe aussi dans d'autres frameworks (Symfony, Zend notamment).
MVC, de même, dispo en home made.

[dukoid]

Plutôt que de répondre avec de la mauvaise foi, on pourrait savoir comment sous Symfony2 tu vas gérer des utilisateurs avec des droits ? Un exemple simple, juste un site accessible par enseignants et élèves, les élèves peuvent consulter, les enseignants peuvent insérer des données.

les rôles ?

TWIG est disponible aussi si on fait du home made. J'envisage de l'utiliser, c'est en discussion avec les gens avec qui je bosse.
Les services, ça existe aussi dans d'autres frameworks (Symfony, Zend notamment).
MVC, de même, dispo en home made.

et bien alors pourquoi j'irai voir ailleurs puisque Symfony propose tout ça comme les autres framework ?

[DarckCrystale]

les rôles ?

Oui. Qui accordent des droits.

et bien alors pourquoi j'irai voir ailleurs puisque Symfony propose tout ça comme les autres framework ?

Parce que non content d'offrir les mêmes avantages, ils en ont d'autres, comme par exemple la rapidité de compréhension de la structure, la facilité de développement, les outils proposé de base dans le framework, la légèreté (rapidité d'exécution).

[dukoid]

Oui. Qui accordent des droits.

tout ce que je sais c'est qu'à la connexion tu fais un event sur le successLogin et tu peux charger ou pas des droits en fonction de paramètres ....
vu que je ne connais pas les contraintes, ton sujet ...... je vais répondre basiquement : un droit a été accordé par celui qui a le droit d'accordé ... (hierarchie, groupe) j'en sais rien

je vais donc pas répondre à ce questionnaire d'évaluation.

Parce que non content d'offrir les mêmes avantages, ils en ont d'autres, comme par exemple la rapidité de compréhension de la structure, la facilité de développement, les outils proposé de base dans le framework, la légèreté (rapidité d'exécution).

non, non et NON. tout ça c'est subjectif.
je trouve Symfony facile de développement, je comprends bien la structure, les outils sont sympa (composer, la barre d'outils, les commandes...) et je le trouve rapide. (certes pas en mode DEV pour l'analyse des données de la barre d'outils) mais en PROD c'est correct.


alors qu'est ce que vous voulez me vendre ? m'obliger à partir ailleurs alors que je suis très bien et offre la même qualité que les autres framework. pourquoi vous insistez à m'imposer à moi et à tous. arrêtez SVP d'imposer vos avis subjectifs comme une vérité absolue.

[Nico_F]

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"

Pour finir, j'aime particulièrement la vision de Kris Wallsmith et la manière dont il construit des apps Symfony => http://fr.slideshare.net/kriswallsmi...s-symfony-apps

[DarckCrystale]

tout ce que je sais c'est qu'à la connexion tu fais un event sur le successLogin et tu peux charger ou pas des droits en fonction de paramètres ....
vu que je ne connais pas les contraintes, ton sujet ...... je vais répondre basiquement : un droit a été accordé par celui qui a le droit d'accordé ... (hierarchie, groupe) j'en sais rien

je vais donc pas répondre à ce questionnaire d'évaluation.

Tu ne saisis pas la question, je pense. Tant pis.

non, non et NON. tout ça c'est subjectif.

Ton avis l'est également. Et c'est d'ailleurs le but de ce topic. Donc critiquer le fait que les avis donnés sont subjectifs n'est réellement pas un contre argument valable.

alors qu'est ce que vous voulez me vendre ? m'obliger à partir ailleurs alors que je suis très bien et offre la même qualité que les autres framework. pourquoi vous insistez à m'imposer à moi et à tous. arrêtez SVP d'imposer vos avis subjectifs comme une vérité absolue.

De un, ce n'est pas forcément toi qu'on cherche à convaincre, pour ma part je préfère donner des informations à d'éventuels lecteurs qui auraient besoin d'information pour faire un choix de framework. De deux, personne n'impose rien, tu peux bien (et les autres aussi) perser ce que tu souhaites. On donne nos retours pour que d'autres n'aient pas à rencontrer nos problèmes ou que d'autres décident de prendre Symfony2 en framework. Ce n'est que de l'information permettant de faire un choix, chaque lecteur aura droit de se faire son propre avis.

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.

Pour nous, réellement, le plus dur à été de comprendre cette notion de bundle. En fait, on pourrait se contenter de faire soi-même un seul énorme bundle par application, pour débuter à mon sens c'est le moins immonde à faire. Cependant, il faut quand même avoir cette idée de "développement d'extensions, de briques logicielles réutilisables dans d'autres projets, ou en tout cas globalement indépendantes les unes des autres".

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.

Quand on commence sur Symfony2, c'est ce qu'on utilise pour apprendre.

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.

Sur le framework qu'on fabrique, nous faisons en sorte que les objets possèdent une méthode save() car on a vraiment apprécié. Cependant, on utilise du réel SQL pour écrire nos requêtes. Un ORM peut servir à uniquement mapper les dépendances pour savoir dans quel ordre on doit lancer les save() si on en a un qui est appelé et qui dépend d'autres choses, sans pour autant avoir besoin de cet objet servant à enlever le maximum de SQL du code.
Je rajoute également : en ne faisant pas du SQL pur et en utilisant les outils de type PDO, on passe à côté des spécificités des différents SGBD. Parfois, ça n'est pas important, mais si on a décidé d'avoir un PostgreSQL plutôt qu'un MySQL, ça peut aussi être pour pouvoir utiliser les fonctions internes et spécifiques. En ce sens, avoir la main sur le SQL est plus intéressant (moins abstrait plus exactement).

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.

Je suis d'accord sur ces points.

[dukoid]

pour ma part je préfère donner des informations à d'éventuels lecteurs qui auraient besoin d'information pour faire un choix de framework.

je me dois de rectifier quand je vois des affirmations exagérées ou fausses qui peuvent induire en erreur le lecteur surtout quand il y a un caractère subjectif

[Ben_74]

Il serait trop façile de conclure : "chacun prêche pour sa paroisse" .. Il y a du bon et du mauvais partout, il ne faut à mon sens, ne pas se mettre d'oeillères et regarder ce qu'il se fait ailleurs ..
Ce sujet a toujours animé des débats enflamés sur la toile, autour de moi, d'ailleurs, il y a des fanatiques extrémistes et également des personnes qui le pratiquent depuis 4 ans et qui savent faire la part des choses .. tout étant finalement une question d'ouverture d'esprit .. à moins de ne rien avoir compris depuis 10 ans, si je ne suis pas un développeur, si je me suis complétement planté d'orientation .. ce que je n'exclus pas .. mais j'aimerais tout de même que l'on me démontre l'inverse

[dukoid]

ben_74, je ne pense pas qu'on puisse se planter complètement. Comme tu dis, il y a du bon et du mauvais partout donc quelque soit le choix on ne se plante pas complètement.
chaque framework permet de gagner du temps et en maintenance. certes on va peut être aller plus vite avec tel ou tel framework mais globalement c'est toujours mieux que de dev en php pure.

quand tu cherches un avis sur tel ou tel sujet c'est le boxon, chacun à un avis différent et surtout ce qui m'énerve le plus c'est les avis subjectifs sans données, sans preuve, sans fondement voir fausses .. "on dev plus vite", "c'est plus lent" patati ....... ça me saoule !



Symfony

les qualités :
Twig : une merveille. je ne peux plus m'en passer.
les routes : super pratique et simple.
les services : puissant, tout en objet.
la validation de formulaire : assez simple à mettre en oeuvre et assez puissant pour faire de la validation de formulaire dynamique.
mvc : un bon compromis. à chacun sa place (la logique d'un coté, le modèle dans un autre et la vue dans un autre). plus de mélange illisible.
la pérennité : Symfony existe depuis longtemps et n'est pas prêt de s'arrêter. symfony2.7 sera compatible avec la nouvelle version de Symfony la 3 donc (prévu en 2016).
la documentation : une bonne documentation officielle (en Français jusqu'à la 2.6 et qu'en anglais depuis la 2.7)
la fiabilité : Symfony est fiable et suivie de correctif régulier et rapide.

les défauts :
doctrine : le query language un peu complexe et des perfs discutable (mais on peut se passer de doctrine s'il le faut).
la création de formulaire complexe : un peu hardu à coder (formulaires imbriqués....)
l'apprentissage : un peu plus long que les autres frameworks
la documentation de certains bundles : assez légère je dirais

[pmithrandir]

Je vais essayer d'actualiser ma réponse précédente...

Nous utilisons symfony 2 dans mon équipe, surtout à cause de mon impulsion de départ. J'avais de l'expérience avec la version 1 du framework, avec java, avec cakePHP, etc... et j'ai eu envie de découvrir symfony 2. J'ai bien galéré, mais en 2 semaines, on est déjà pas mal à l'aise.

Donc maintenant, ce que j'aime bien :
- il force le développeur à travailler de manière standard. Par là, j'entends que tous les dev font les choses à peu près de la même manière dans l'équipe, parce que le framework les force en ce sens.
- Le découpage de tous les projets se ressemble vite. On a pas de surprise(tient un module en python ou en D) et on s'y retrouve vite, ce qui est pratique quand on travaille sur 8 projets en parallèle sur 2 ans.
- Il est loin d'être ridicule en terme de perf. On travaille avec des BDD de plusieurs milliards de lignes sans sourciller.
- Il permet d'aller très vite. La standardisation qu'apporte symfony avec d'autres outils nous permet d'avoir des applications simples, mode crud, avec API prête en quelques heures, ready pour la prod. C'est des trucs ultra basique, mais ca fonctionne.
- On maximise la réutilisation de code avec certains bundle maison qu'on remet dans plusieurs projets(le module d'auth spécifique à notre boite)
- nos bugs sont très limité
- notre sécurité est mieux garantie. Par exemple CSRF, même si c'est 2 minutes, faut penser à le faire... et je vois pas comment tu fais ca en 2 lignes. Aussi, doctrine nous protège facilement des injections SQL, etc... pleins d'avantages qui font qu'on a moins peur de mettre de juniors dessus...
- la réutilisation facile de certaines partie de code pour ajouter d'autre fonctions. Par exemple, ajouter une API sur un site, ca peut se faire en 4-5 heures... avec un résultat propre et documenté.

Ce que je n'aime pas :
- les 10 jours initiaux du début
- le coté magique qui fait que certains ne jurent que par certains bundle au lieu de se faire le travail. (j'en ai un peu marre du look and feel sonata dans les applications pour ne pas refaire les listes ordonnées et filtrées...) même si je vois le temps gagné(ca prend 10 minutes au lieux de 2 jours)
- Doctrine qui ne fait pas les UNIONS ou les sous requêtes.


En résumé, Symfony est très pratique pour faire des applications métiers de manière industrielle, dans une boite pas agile avec une vraie équipe d'exploitation qui a autre chose à faire que de découvrir un nouveau système a chaque logiciel livré.
En revanche, pour un site web ou un one shot... surtout à la maison, je ne sais pas si il vaut le coup. Je l'utilise toujours parce que je capitalise les connaissances acquises dans le travail, mais je ne le conseillerai peut être pas dans un autre cas.

Super point par contre, symfony empêche beaucoup de truc dégueu d'apparaitre... ou du moins ils sautent aux yeux. Donc on évite les raccourcis fait par un stagiaire qu'on ne retrouve plus.

[Ben_74]

Tout à fait d'accord

Je tiens à préciser deux choses super utiles pour prendre en main symfony ( et devraient être "shippée" de base avec SF ) :
- \Doctrine\Common\Util\Debug::dump($object);
- remplacer la méthode twig dump de base vers un dump similaire

Combien de fois j'ai vu mes collègues râler dès qu'ils effectuaient un dump sous symfony ..

[Nico_F]

@Ben_74 J'ai longtemps été adepte du \Doctrine\Common\Util\Debug::dump($object) aussi, pour avoir fait planter mon navigateur des centaines de fois.

Mais il faut croire que tes voeux ont été exaucés : maintenant il y a le VarDumper.

[Ben_74]

Nice .. j'avais à l'époque construit le mien pour empêcher les récursions, parcourir les collections doctrines .. éviter certaines relations non nécessaire avec un input -> jquery -> filter .. je vais essayer de ce pas ce qu'ils nous ont pondu

[Walva]

Ca fait maintenant plus de 2 ans que j'utilise Symfony 2 et j'adore. J'avais commencé jeune à programmer en PHP et en sortant des études, aucun employeur n'a voulu m'employer autre chose que du PHP à cause de mon expérience, j'aurais du éviter de mentionner mes XP d'étudiant. BREF, je voulais plus faire du PHP, mais plutôt me diriger vers Java ou .NET... Histoire d'avoir quelque chose de costaux pour faire des web app d'entreprises. Mais Symfony 2 m'a réconcilié avec PHP.

Pour moi SF2 est le framework qui a l'architecture la plus solide. C'est dommage qu'il n'est pas toujours évident de séparer la business logique du framework, la documentation va rarement dans ce sens, meme si c'est tout à fait possible. Je conseille de lire des sujets sur le DDD pour faire de bonnes applications solides. Exemple.

Pour le RAD, la doc est bien faite et tout résultat peut se faire très rapidement si ont concède quelques concessions et qu'on respecte les conventions.
Pour un petit-moyen projet, j'utilise JMSDiExtraBundle pour ne pas m’embêter avec les déclarations de service verbeuses et j'utilise les annotations @InjectParams, @Inject et biensur @Service. Gain de temps fou.

J'ai testé CakePHP, Laravel, AuraPHP etc... Symfony 2 est pour moi bien meilleur même si Laravel est pas mal. (je ne supporte pas mélanger la persistence et la logique business

Le seul défaut est donc de ne pas communiquer assez de best practice pour faire des applications solides avec une logique business clairement séparée du framework.

Avec le framework j'ai fait plusieurs sites Web !

[sseoptic]

Ca fait maintenant plus de 2 ans que j'utilise Symfony 2 et j'adore. J'avais commencé jeune à programmer en PHP et en sortant des études, aucun employeur n'a voulu m'employer autre chose que du PHP à cause de mon expérience, j'aurais du éviter de mentionner mes XP d'étudiant. BREF, je voulais plus faire du PHP, mais plutôt me diriger vers Java ou .NET... Histoire d'avoir quelque chose de costaux pour faire des web app d'entreprises. Mais Symfony 2 m'a réconcilié avec PHP.

Pour moi SF2 est le framework qui a l'architecture la plus solide. C'est dommage qu'il n'est pas toujours évident de séparer la business logique du framework, la documentation va rarement dans ce sens, meme si c'est tout à fait possible. Je conseille de lire des sujets sur le DDD pour faire de bonnes applications solides. Exemple.

Pour le RAD, la doc est bien faite et tout résultat peut se faire très rapidement si ont concède quelques concessions et qu'on respecte les conventions.
Pour un petit-moyen projet, j'utilise JMSDiExtraBundle pour ne pas m’embêter avec les déclarations de service verbeuses et j'utilise les annotations @InjectParams, @Inject et biensur @Service. Gain de temps fou.

J'ai testé CakePHP, Laravel, AuraPHP etc... Symfony 2 est pour moi bien meilleur même si Laravel est pas mal. (je ne supporte pas mélanger la persistence et la logique business

Le seul défaut est donc de ne pas communiquer assez de best practice pour faire des applications solides avec une logique business clairement séparée du framework.

Avec le framework j'ai fait plusieurs sites Web !

Salut Walva,

J'aime bien ton feedback sur Symfony mais je me pose la question : est-ce que Symfony est utilisable pour réaliser un site eCommerce digne de ce nom ? Comparé à Magento, je trouve beaucoup moins de modules additionnels sur le marché et cela m'effraie un peu mème si des développeurs PHP m'ont indiqué préférer Symfony à Magento.

Quel est ton point de vue la dessus ?

---

Sylvestre, Concepteur et administrateur du site optique en ligne Gweleo

[dukoid]

sseoptic, je me permet de te répondre pour t'indiquer le projet suivant : http://sylius.org/ ecommerce Symfony
et puis avec Symfony on peut réaliser n'importe quel gros ou moyen projet, c'est sa raison d'être. après magento et Symfony n'ont pas le même but.

Avec magento tu as un site de e-commerce tout prêt avec une configuration standard ou tu effectues divers paramétrages, configurations si et là.
Si tu veux sortir des plates bandes de magento, des nouvelles fonctionnalités, de nouvelles intéractions.... c'est là que ce complique les choses comme tous les CMS d'ailleurs.

Et donc avec Symfony, tu es maître de ton projet et tu en fais ce que tu veux ..... mais il faut tout refaire. (bien que l'on puisse trouver j'imagine divers bundle)

[sseoptic]

@dukoid, merci, effectivement Symfony s'utilise bien en amont, mais coté développeurs, j'en ai entendu bcp de bien (bien conçu, correctement documenté). Coté CMS, j'ai aussi trouvé celui de shopware (basé sur Symfony a priori), prêt à l'emploi mais plutot cher comparé à des CMS comme Magento où pour 1000/1500e on dispose de toutes les extensions souhaitables.

Et quelle est la grosseur de la communauté de Symfony, c'est un produit qui vit plutôt bien ?

---

Sylvestre, Concepteur et administrateur du site de lunettes de vue Gweleo