en fait je pense que ton opinion vient du fait que Zend est beaucoup plus souple que les autres frameworks : il permet d’utiliser ses composants indépendemment, comme une boite à outil.
mais également d’utiliser son architecture MVC. c’est toi qui choisis

il est moins directif mais je trouve que c’est un avantage (par exemple au début tu testes en n’utilisant que les composants dont tu as besoin)
de plus pour moi le but n’est pas de simplement de se faire plaisir en étant “MVC” mais bien de disposer d’une véritable à outil qui fasse gagner du temps
les nombreux services dont tu parles sont donc un plus (comment se plaindre d’avoir des fonctionnalités offertes ! :) )

a noter également qu’il propose l’intégration Ajax (dojo je crois), bientot flex…
et qu’il y a un système de cache
je ne les ai pas testé mais c’est assez connu, donc j’ai pas l’impression que tu es tellement fouillé :)

par contre c’est vrai que la doc est plus “aride”, mais c’est aussi plus structuré car géré par une entreprise
et à coté pas mal de tutoriaux, y compris en francais

donc je ne dis pas que zend est meilleur que symphony (que je n’ai pas testé)
mais sur le coups je crois que tu n’as pas cherché très loin ;)

je ne sais pas si zend est le meilleur, mais il n’est certainement pas brouillon
il est au contraire plus flexible
rappelons que un des créateurs de PHP fait parti de l’équipe de Zend

alors qu’au dernieres nouvelles le créateur de Symphony a claqué la porte si je ne m’abuse ;)

bonne continuation

Je ne développerais pas plus les critiques constructives et parfaitement justifiées.

Mon expérience se limite au Zend Framework que j’ai choisi particulièrement rapidement parce que j’avais un site a faire dans un delais très rapide sans avoir fait de php depuis 3 ans (java depuis). Pas forcement très complexe mais un impératif de temps de 10 jours.

J’aime le fait de n pas avoir un cadre contraint. Ayant fait du free lance il y a 3 ans j’avais utilisé des modules comme smarty, jpcache, adodb.

Le ZF me permettait de concentrer mon apprentissage rapide sur le mvc et d’utiliser ce que je connaissais déja (j’aime avoir le choix des armes ;) )

Donc verdict j’ai sorti le site dans les temps impartis mais j’ai utilisé PDO pour les DAO (en une journée j’ai eu du mal à tout faire en Doctrine ) et Zend Cache . Il y a quelques très bonnes idées comme le routage et surtout le reverse des règles de routage .

Sur symphony j’ai vu que c’était effectivement bien codé. Comme le faisait remarquer quelqu’un , donner des cadres rigides a parfois du bon dans un projet PHP (quand on a fait 3 ans de rigueur Java certains codes php peuvent vous faire déprimer - enfin les nommages etc … parce que le code crade existe egalement en Java)

Quels sont les objectifs d’un framework web ?
1 - fournir des librairies de plus haut niveau que celle de php (ex: gestion du cache, des sessions, des formulaires et j’en passe)
2 - accélérer le développement d’application web avec divers mécanismes, ce qu’on appelle RAD : “Rapid Application Developpment”. C’est à fire : fournir donc un cadre de développement avec des outils comme des générateurs, des méthodes magiques, des outils pratiques
3 - fournir un cadre qui permette une très grande souplesse/flexibilité (contrairement aux cms), une bonne évolutivité du projet (et du framework d’ailleurs), une reprise du code facile pour soi même (sur le tard) ou un autre développeur
4 - utiliser des technologies récentes et performantes si possible : php5, ajax, pdo, etc.
5 - et bien sûr comme tous projets open-sources : être stable, pérenne, actif, avoir une bonne communauté, une bonne doc, un bon site, etc.

Mes impressions :
Ces 2 frameworks se destinent à des développeurs assez expérimentés (contrairement aux CMS qui peuvent être plus ou moins gérer par des bricoleurs php) pour des projets de petite à grande taille (oui on peut aussi utiliser SF ou ZF pour de petits projets quand on les connaît bien, non ce n’est pas superflue).

ZF a commencer avec un système de briques disparates pas assez liées pour arriver à un ensemble cohérent et modulaire.
SF à fait le contraire : au départ, un système cohérent assez complet et monobloc (pour utiliser une seule classe sans les autres par exemple) qui évolue vers un système plus modulaire : nombreux plugins, version 1.1 à venir plus modulaire/découplée.

- SF exigent de connaître une bonne partie de son fonctionnement (et de sa philosophie ?) pour bien l’utiliser vu qu’il est plus “monobloc”.
- ZF permet (apparemment) de n’avoir qu’à connaître le fonctionnement de certaines classes pour commencer à l’utiliser.
Bref, SF à peut-être une courbe d’apprentissage plus longue, mais ça en vaut largement la peine je pense. C’est pour ça que ce FW exige pour être populaire d’avoir une documentation attrayante et efficace, sinon il n’y aurait personne pour l’utiliser: cette usine à gaz ferait “peur”.

Sur le 1er point, les librairies :
- ZF permet, comme PEAR, d’utiliser ces librairies sans avoir à utiliser tous le reste du framework. Certaines librairies (importantes?) sont encore en cours de développement.
- SF fournit des librairies plus abouties, plus disparates (ajax, internationalisation, orm, etc )- mais qui nécessite d’être utiliser dans le cadre d’un projet Symfony uniquement (!).

Sur le 2ème point, “Rapid Application Dev.” :
J’ai l’impression globalement que SF est meilleur : il fournit beaucoup de choses qui permettent de développer (très) rapidement une application web : génération de modules/applications, générateur d’admin (extensible), plugins, gestion de la configuration, orm, helpers, symfony web bar, environnement de développement, log, etc. Tout ceci est accessible dès la création d’un projet rapidement en ligne de commande ou non, en tout cas sans avoir à coder quoi que ce soit à part un ou 2 fichiers yml décrivant le projet.

Sur le 3e point, j’ai l’impression que les utilisateurs de ZF considère que ZF est meilleur. D’un certain coté oui car il est possible de n’utiliser que certaines classes de
ZF et d’organiser ces fichiers comme on veut. De l’autre coté, quand on connait le cadre de Symfony : on bosse tous de la même façon et en respectant mieux les “PHP Best Practice” que SF tant à imposer. De plus, un projet est toujours organisé de la même manière (une manière très cohérente et extensible) donc un développeur tiers, si il connait SF, peut reprendre un projet très facilement. Idem pour reprendre son propre projet au bout de 6 mois, 1 an…

4ème point, “projet open-source” :
Les 2 projets semblent faire jeu égal sur ce point et sont tous les 2 très fort.

En contre partie, par rapport à ZF :
- Une courbe d’apprentissage qui semble plus longue, peut-être plus ardue, heureusement une bonne doc et une bonne communauté.
- Une structure des fichiers assez figé (mais c’est pas plus mal je pense) et de très nombreux fichiers pour un projet.
- L’obligation avec la version 1.0, d’utiliser l’ensemble du “moteur” (core) de Symfony ou rien du tout (ex: on peut pas actuellement utiliser une classe de ceci ou cela sans le reste).

Pour conclure :
- ZF est à l’image de PEAR, plus découplé, de plus bas niveau (-> php)
- SF est à l’image d’un CMS, plus monobloc, de plus haut niveau (-> web).
- Néanmoins, ZF ne peut pas être comparé à PEAR et SF ne peut pas être comparé à un CMS.
- ZF est donc peut-être plus simple à prendre en main au départ : moins d’apprentissage pour commencer.
- SF nécessite donc un vrai “apprentissage” assez long et on en apprend tous les jours.
- SF impose un cadre strict mais grâce à cela permet beaucoup beaucoup de choses.
- ZF est “jeune” donc peut-être encore quelques défauts de jeunesse : il reste des choses à développer, une cohérence qui évolue (?), des docs à finaliser (?), etc.
- SF est possède une version stable et maintenue depuis 1 an : les classes, la doc sont terminées et ne bougent plus (mis à part versions mineures), de nombreux plugins sont présents. La nouvelle version 1.1 sortira dans 1 mois environ.

Yann, tu trouveras la description du système de plugin ici : http://www.symfony-project.org/book/1_0/17-Extending-Symfony#Plug-Ins

C’est un peu plus puissant que ce à quoi tu penses.

Je suis désolé, mais je ne vois toujours pas le soucis au niveau de la flexibilité et de la réutilisation. Je cherche pourtant. Les contraintes imposées par Symfony par exemple sont minimes (les applications sont ds le répertoire apps, les libs dans lib, le cache dans cache, les plugins dans plugins) voir n’en sont pas vraiment car tout le monde cherchera à “industrialiser” ses développements en normant ses projets ; et finalement imposera en interne une organisation similaire.

Si tu veux réutiliser ton code, tu le packages dans une classe comme tu le ferais avec ZF. Si il est destiné à un projet SF tu peux faire un plugin (ce qui te permets plus de choses).

Les autres arguments sont des points retrouvés dans tous les frameworks (abstractions etc.) et ZF présentent quelques manques gênants (qui vont vraisemblablement être comblés certes).

Je reste donc un poil sceptique mais attentif ;-)

J’aimerais mentionner que je suis en accord avec tous les points de Philippe

Pour moi, les avantages principaux sont les suivants:
* Documentation (excellente pour les gens qui lisent, moins pour ceux qui regardent seulement les pages)
* Le processus de communauté
* Le peer review du code
* Des tests unitaires sur toutes les composantes
* Pas restreint à utiliser MVC quand on ne le veut pas
* Structure de namespace facilite l’intégration de ses propres composantes

La raison pourquoi le framework est très extensible est que toutes les fonctionnalités sont définies par des interfaces ou des abstractions. Jamais la composantes directement. Comme ça, tu peux changer le processus de routing entièrement, changer le fonctionnement des vues, ajouter des modes d’authentifications et encore plus. Le framework ne vient pas avec des “plug-ins” pour interagir avec les autres frameworks, mais c’est certain qu’il propose les endroits de branchement et qu’il n’y a rien de plus a faire qu’un petit wrapper. Le framework vient avec une bonne gamme d’implantations de ses abstractions à la base, mais il laisse toujours la porte ouverte. Dans un système d’entreprise, il y a toujours des systèmes un peu étranges à brancher.

Ce n’est pas le framework le plus facile à démarrer et il y a beaucoup de choix à faire au début, mais c’est plutôt bien parce que chaque projet a des priorités différentes et le framework s’adapte très facilement. Mais sur un projet de plusieurs mois, passer quelques heures à bien mettre en place les briques de la fondation, c’est pas si mal.

D’ailleurs, le framework s’améliore rapidement. Les composantes s’intègrent de mieux en mieux. Dans les versions initiales, l’absence des vues était __presque__ une critique réelle tellement la vue et le contrôleur étaient des concepts distincts, mais cette situation est très loin d’être vraie en ce moment. Il existe présentement une lacune de ce type par rapport aux liens entre les filtres, les validations et les contrôleurs, mais ce n’est rien de très complexe à régler et je m’attends à ce que la situation s’améliore.

Je vois le framework comme un choix à long terme. Autant côté extensibilité que pour son amélioration à travers le processus de communauté et la grande visibilité qu’il a. Le support par un joueur important est aussi important.

Pour le reste Julien et Philippe ont précisés mes pensées ^^.
De ce que je connais de Symfony tu dois te “plier” à une certaine architecture/structure de projet.
Avec le ZF tu peux comme dit plus haut l’utiliser comme libraire annexe ou en MVC :).
Je me sens plus libre à déveloper avec le ZF. Pouvoir le réutiliser dans un autre projet. Etc..

J’aime Symfony même si comme Philippe je n’ai clairement fait que le regarder de haut. (Question de temps).

Pour moi la conclusion est claire : ZF et Symfony ne s’adressent pas tout à fait au même public.
De la même manière, leurs roadmaps, leurs forges, leurs guidelines et leurs objectifs ne sont pas exactement les mêmes, et c’est tant mieux, la diversité est très bonne.

Je pense qu’un indécis se frottera aux 2 bestioles, et trouvera sa satisfaction selon ses objectifs.

Je te confirme que ZF et Symfony boxent vraiment dans la même catégorie : les projets complexes et de grandes tailles. Manifestement les concepteurs des frameworks ont fait des choix différents dès le départ … et c’est tant mieux !

Je n’ai toujours pas compris pourquoi ZF offrait une meilleur flexibilité que d’autres frameworks mais je ne désespère pas. Merci pour toutes les autres infos !

Je suis un utilisateur averti du Zend Framework, mais par contre, je n’ai regardé que de très loin Symfony. Je ne peux pas faire de comparaison non plus.

Pourquoi j’ai adopté le ZF
————————
- C’est pensé pour des applications complexes. C’est effectivement peu performant pour faire un formulaire de contact en 3mn. Par contre, pour des applications web complexes, il est très souple, bien codé, uniforme et pérenne dans le temps (notamment, les Acl, le cache, les authentifications et le MVC sont très propres et très pratiques).

- En interne il est très bien codé. C’est bien pensé pour être étendu, un peu à la manière des librairies java. Leur système de namespace et simple et efficace et l’architecture est toujours pensée (injection de dépendance systématique notamment) pour qu’on puisse toujours faire évoluer un comportement par défaut. *Si un besoin bizarre arrive, on n’est jamais bloqué par le framework.*

- Il est soutenu par Zend. Ca suppose une certaine pérennité dans le temps.

- Il avance de façon rigoureuse : bonne compatibilité ascendante des versions, tests unitaires complets, process clairs et établis pour les évolutions et versions suivantes. Là encore, le produit donne une impression de robustesse.

- Le MVC du ZF n’est qu’une option, on peut n’utiliser que les librairies si on le souhaite. Le ZF peut ainsi progressivement s’insérer dans des projets existants, même fondés sur symfony !

Bref pour moi les 3 points importants :
- stable dans le temps
- bien codé, bien pensé
- souple : si un besoin est ésothérique, on n’est jamais bloqué par le framework

Je vais reprendre tes points un par un :
—————————————

- La documentation est vraiment aride,
Personnellement, je la trouve plutôt bien faite, je pense qu’il y a une question de goûts… Par contre le “quick start” est un peu planqué, je t’accorde que c’est dommage :
http://framework.zend.com/manual/en/zend.controller.html#zend.controller.quickstart

- il manque des bouts de MVC comme la vue !? (bien que visiblement le composant soit disponible, il n’est pas documenté !?).
Elle est documentée (cf Zend_View et Zend_Controller). Cependant l’idée du ZF est qu’on ne soit pas bloqué avec la vue du ZF, on peut très bien utiliser Smarty ou un autre moteur de template. Le ZF offre souvent la possibilité de changer son comportement par défaut.

- que viennent faire les classes de connections aux services d’Amazon, de Flickr etc … pour moi c’est hors périmètre d’un framework (enfin ça ce n’est pas grave)
hum… ça se défend… Moi j’aime bien l’idée d’avoir une seule archive un peu comme le language PHP accumule plein de fonctions qui sont souvent dans des librairies à part…

- on doit fabriquer le cache à la main
heu… non : il y a plusieurs systèmes de cache pour différents usages, cache de données, cache de pages, même cache de résultats de fonction, classes… Et si tu veux cacher des trucs plus ésothériques, tu peux utiliser les fonctions de cache standard “bas niveau” du ZF qui facilitent déjà bien la tâche… là je ne vois pas le point.

- pas de système de plugin (c’est dommage car ce système séduit les utilisateurs comme on peut l’observer pour CakePHP ou Symfony)
C’est vrai. Le ZF propose une arbo générale qui permet de l’étendre simplement (avec un système de namespace bien fait), mais pas de système de plugin complet. Dans le MVC, un système de modules permet de bien séparer certaines fonctionnalités.

- pas de gestion d’environnements (dev, test, prod …), rien pour vous aider à instancier / déployer vos applications
Hum… je n’aurais pas dit que ça faisait partie du périmètre d’un framework… mais bon, pourquoi pas…

- rien pour les formulaires :-( (si il y a un composant de validation)
C’est un vrai point noir, un composant Zend_Form arrive dans la prochaine version (1.5.x - en février 2008).

- pas de helpers pour faire de l’Ajax.
Certes, pas en standard. De nombreuses extensions sont en cours de discussion (un process communautaire est mis en place pour le développement de chaque nouvelle fonctionnalité)

- pas de scaffolding
effectivement, personnellement, je n’aime pas trop, ça ne m’a pas dérangé. Dès que le projet est un peu complexe et qu’il évolue, c’est rapidement l’enfer de gérer des générations de code. Clairement le ZF s’adresse à des projets assez importants.

Si vous avez lu ma prose jusqu’ici, je vous félicite :-)

En conclusion, je pense que les gens ont des approches différentes du code, des façons de raisonner différentes et des projets différents. Je ne sais pas s’il y a un framework “universel” qui satisfasse tous les besoins et tous les développeurs. Au delà des qualités et des défauts respectifs de chaque framework, il y a aussi des questions de goûts, mais quand on lit les articles sur Symfony et sur le ZF, j’ai l’impression que les deux sont de bonne facture.