4 mois.

> Parce que tu ne maitrises pas l’outil, tout simplement.

C’est exactement où Palleas voulait en venir. On avance qu’un framework fait gagner du temps. Or, comme tu me le fais remarquer, il faut maîtriser l’outil. Sauf que la maîtrise ça prend du temps, et là c’est le serpent qui se mort la queue.

> Parce que tu ne l’utilises pas correctement. Si vraiment tu as des gros soucis de performances, tu peux générer des pages statiques (extended cache)

Très simple de sortir une technique qui va forcément m’aider à résoudre tous mes problèmes de performances. De même que de me signaler que je ne l’utilise pas correctement.

> J’aimerais que tu détailles. Quel est le problème ?

La tonne de fichiers n’est pas aisée à gérer, Object.php, Object_i18n.php, ObjectPeer.php, Object_i18nPeer.php, sans compter les fichiers de modèle généré. La gestion des traductions via des catalogues XML qui peut être bloquante quand tu veux “naviguer” d’une langue à une autre, etc. (pas envie de m’éterniser là dessus)

> Quand tu changes la configuration d’une application, tu ne regénères pas le cache ?

Non, encore moins en dev.

> C’est une blague ? Ou un troll ?

Non, et mon commentaire ressemblait moins à du troll que la suite de ta discution. Je n’ai pas voulu démonter Symfony, je l’ai utilisé en exemple

> Pas eu besoin de trop tester. Je suis abonné aux mailing-list française et anglophone et ça a l’air plutôt réactif.

Donc pour développer avec Symfony il faut se spécialiser en Symfony ? Pas le temps de m’abonner aux mailing-list, pas l’envie, pas le besoin. Quand je développe je veux trouver des solutions à mes problèmes, si je n’en trouve pas (à cause d’une doc trop maigre), je demande. Je considère qu’une communauté n’est pas réactive quand il n’y a pas de réponse sous 24h (surtout dans le cas d’un framework qui se dit “professionnel”), manque de pot, à chaque fois j’ai du attendre plusieurs jours pour ne pas avoir de réponse satisfaisante.

> Oui. Où veux-tu en venir ? Quand tu fais deux projets, tu réécris tout ? Si tu découvres une faille ce sera pareil.

J’ai du mal m’exprimer. Prenons un exemple. Un framework X, 2 sites développés avec ce framework. On trouve une faille dans X, les 2 sites y sont exposés. Les développeurs n’ont pas le temps de mettre à jour leurs frameworks car ils travaillent sur d’autres projets et que ça les emmerdent d’avoir ça à faire. Là où je veux en venir, c’est qu’à partir du moment où le framework est open-source il est plus exposé aux fouineurs qui cherchent une faille pour l’exploiter sur un site. Ce qui est déjà plus difficile dans le cas d’un projet sans framework (ou avec un framework maison). Je ne dis pas du tout qu’il ne faut pas utiliser de framework ! Je dis simplement que c’est utopique que de croire que puisqu’on utilise un framework on va forcément faire une application sécurisée. Je suis plus clair ?

> A ma connaissance Symfony est le seul framework (en php) qui assure le support d’une version majeure (la 1.X pour le momentà pendant 5 ans.)

Qu’entends-tu par support ? Le fait de payer le créateur du framework pour adapter le code au fur et à mesure des versions ? Dans ce cas je n’imagine même pas le budget TMA… Je rebondis sur un passage du commentaire de Hugo (désolé Hugo, j’ai la flemme de répondre au tiens) :

> Là encore Non ! Le code que tu développes pour Symfony 1.0 est compatible à près de 90% avec le framework Symfony 1.1

1. 90% C’est trop peu
2. Qui va me payer pendant que je dois corriger les 10% ?
3. D’où sort ce chiffre ? Peut-être que dans mon application les changements de la 1.1 vont me valoir 70% de code à réécrire

> Décidément tes messages ressemblent de plus en plus à un troll.

Arrête de tout prendre contre Symfony…

En revanche, ils ont du mal à comprendre que le graphisme c’est complètement statique et que finalement tout ce qui fait la dynamique de l’application qu’ils ont acheté provient du travail du développeur : formulaire, alimentation de la BDD, envois de mails automatiques…

Penser, concevoir et animer tout une application logicielle est tout aussi complexe (si ce n’est plus) que de créer une interface graphique et ergonomique. Et encore l’ergonomie entre elle aussi en compte dans le développement. Là où le poste de développeur est encore plus ingrat, c’est que pour beaucoup d’entreprises, on demande au programmeur d’aligner du code “fonctionnel” et le plus rapidement possible… Qui dit “rapidement” dit aussi pas forcément très clean comme code. On se retrouve donc avec un programme qui “marche” mais qui peu maintenable, peu sécurisé, imbuvable à relire…

Finalement c’est surtout ce que je trouve dommage dans notre métier. On se retrouve d’une part à l’arrière plan dans la réussite d’un projet puisque l’on ne côtoie pas vraiment le client mais en plus, on nous demande régulièrement d’écrire limite…

J’ai été le seul à répondre à la proposition et apres avoir rencontré le gars il s’est avéré que 2mois au SMIC c’était trop cher pour leur assoc, mais bon en meme temps c’est pas une entreprise …

Par contre 300€ c’est vraiment histoire de dire que c’est pas fait gratos, même 1000€ c’est pas assez par rapport a ce qu’une entreprise peut vendre.

en production (professionnellement) j’utilise bien entendu symfony 1.0 mais je commence tout doucement à lorgner du côté de symfony 1.1 notament pour le nouveau framework de gestion des formulaires

Oui je pense aussi. Pour le moment, Propel satisfait pleinement mes besoins. Je ne m’en plains pas.

>> Tu fais un script (un peu comme les tests unitaires) qui fait toutes les requêtes que feraient tes visiteurs. Une fois cela fait tu déposes tout cela sur ton site. Cela a un énorme avantage, si par exemple, tu as des pages extrêment complexes, tu ne pénalises personne.

Merci je note ça de côté

Petite question, tu utilises Symfony 1.0 ou Symfony 1.1 ?

Pour reprendre les propos d’un des intervenants d’un déjeuner symfony, quand tu en es à trouver propel lent, c’est que déjà tu as optimisé plein d’autres choses avant.

> Euh là je serai curieux de savoir comment ça marche Ca m’intéresse pour mon prochain projet Symfony qui utilisera intensivement MySQL.

Tu fais un script (un peu comme les tests unitaires) qui fait toutes les requêtes que feraient tes visiteurs. Une fois cela fait tu déposes tout cela sur ton site. Cela a un énorme avantage, si par exemple, tu as des pages extrêment complexes, tu ne pénalises personne.