Pourquoi utiliser Zend Framework quand on peut utiliser Symfony ?

Connaisseur averti de Symfony (que j’ai pratiqué sur de nombreux projets) je m’intéresse vivement aux frameworks PHP. J’ai utilisé d’autres frameworks ; par exemple, Code Igniter qui est quand même pas mal, (surtout si on est coincé avec PHP4) mais qui reste pour moi valable uniquement pour des petits projets (pub gratuite : un joli site réalisé avec ce framework par un de mes amis).

En ce moment, tout le monde s’excite beaucoup autour de Zend Framework. Je suis donc allez y jeter un coup d’œil ; Zend avait annoncé des livraisons importantes et mon dernier avis sur la question datait un peu.

Là, je dois vous dire chers lecteurs, que je suis vraiment désappointé. Franchement, vous lui trouvez quoi au Zend Framework ? (c’est une vraie question – un peu provocatrice oui – mais tout de même une question).

  • La documentation est vraiment aride,
  • il manque des bouts de MVC comme la vue !? (bien que visiblement le composant soit disponible, il n’est pas documenté !?),
  • 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),
  • on doit fabriquer le cache à la main,
  • 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),
  • pas de gestion d’environnements (dev, test, prod …), rien pour vous aider à instancier / déployer vos applications,
  • rien pour les formulaires 😦 (si il y a un composant de validation), pas de helpers pour faire de l’Ajax,
  • pas de scaffolding

Mon impression est que ZF a été développé de manière un peu brouillonne et désordonnée. Quelque chose de satisfaisant du point de vue d’une librairie mais pas d’un framework (comme PEAR par exemple). Je ne dis pas que le travail fait autour de ZF est mauvais (je trouve, par exemple, certaines classes très bien faites comme Zend_Memory ou Zend_PDF) mais tout ça manque de liant et de finition pour faire un bon framework.

Je pense toutefois qu’un défaut d’approfondissement dans mes recherches est la cause de tout ces manques affichés – je creuse. Si vous avez des arguments pour me faire changer d’avis, je serais ravi de vous lire dans les commentaires. Pour l’instant je continue avec Symfony.

Non cet article n’est pas un troll. Ceci oui :

troll

Publicités

18 réflexions au sujet de « Pourquoi utiliser Zend Framework quand on peut utiliser Symfony ? »

  1. j0k

    Hello,

    Je n’ai jamais essayé ZF, je suis plus tourné vers l’utilisation de symfony.
    Mais j’ai lu récemment ( http://tinyurl.com/2oz4jx ) que pas mal de composants/amélioration allaient être intégrés dans la prochaine release (fin janvier apparemment) avec notamment les formulaires, ajax, la vue, etc …

    A voir donc 🙂

    Répondre
  2. Yann

    Hey oui le Zend Framework a des défauts. Et il est encore jeune !
    C’est sûr il n’est aussi complet, soudé que symfony ou autre.
    La vue a tjrs existé, le nouveau composant sert + à gérer la structure de la page final.
    Quel genre de système de plugin ?

    Ce qui me plait avec le Zend Framework c’est sa grande flexibilité justement !

    Répondre
  3. olivier

    @Yann : les plugins permettent de réutiliser facilement des fonctions d’un projet à un autre (pas seulement des librairies). Regarde ceux disponibles pour Symfony : http://trac.symfony-project.com/wiki/SymfonyPlugins ). Il y a même un plugin qui permet d’utiliser ZF dans Symfony 😉 .C’est vraiment efficace. Par exemple, au sein d’une même entreprise on peut facilement partager tout le système de login et d’ACL entre toutes les applications (du sso jusqu’au formulaire de login).

    Pourrais tu préciser la flexibilité du Zend Framework ? Je cherche a approfondir le sujet.

    Répondre
  4. Laurentj

    Personnellement j’avais regardé ZF a ses débuts, et j’y avait vu un simple ensemble de classes, une bilbliothèque à la PEAR, avec plus des évolutions sur des classes utilitaires que le développement d’un vrai coeur de framework qui imposerait un vrai cadre de travail. Ça s’est amélioré semble-t-il mais j’ai l’impression que c’est pas toujours ça.

    Répondre
  5. julienp

    Héhé, je m’attendai un jour où l’autre à un billet de ce style quelque part.
    J’ai dépassé largement le stade du troll, donc je vais répondre sereinement.

    ZendFramework tarde à murir, mais promet de belles choses.
    Je suis d’accord que le TTM sous symfony est imbattable, mais Zend Framework offre une fléxibilité plus grande à mon gout que Symfony, et j’aime beaucoup ça.

    Le scaffolding arrive sous ZF (c’est en cours), les plugins sont possibles, il suffit de chercher et de se casser un peut la tête (n’est ce pas là le rôle du développeur après tout ?).

    La vue a beaucoup tardé, je l’admets volontiers, mais Zend_Layout et Zend_Form arrivent aussi, ce mois-ci d’ailleurs, en théorie.

    La timeline de ZF a toujours été allongée. Cependant le code sous ZF doit offrir une grande fléxibilité, c’est pour cela que son développement est lent : lentement mais sûrement.

    Après, on peut toujours débattre autour du mot « framework », mais comme dit : j’ai passé l’age.
    La force de PHP réside dans la diversité des projets qui lui tournent autour, ne l’oublions jamais.

    Répondre
  6. Ping : Pourquoi utiliser Zend Framework quand on peut utiliser Symfony ? - Blog Web 2.0

  7. NiKo

    Je pense que c’est effectivement très aride d’emblée, mais que les composants sont d’une grande qualité. Si je voulais troller un peu, je dirais que les briques du Zend Framework ne font pas grand chose, mais qu’elles le font très bien.

    De quoi par exemple construire un framework plus haut niveau (comme Symfony) sur sa base… Un framework basé sur un framework ?… Ça m’amène à penser que dans le cas du Zend Framework le terme « framework » est peut-être un peu abusif, dans le sens où c’est encore pour l’heure surtout une collection de briques logicielles – comme PEAR (mais la comparaison va s’arrêter là.)

    En résumé, si aujourd’hui j’ai à construire un site internet, je pars sur Symfony; si j’ai un framework à coder, je partirai sans doûte sur le Zend Framework. Mais je suis pas assez neuneu pour développer un framework :p (laurentj, je ne te vise pas, hein.)

    Répondre
  8. olivier

    @julienp : pour moi un framework ou une librairie qui nécessite de « me casser la tête » n’est pas pour moi. Je suis informaticien, je suis fainéant ;-). Je suis d’accord avec toi pour dire que bcp de choses bien arrivent à voir toutes les annonces !

    @NiKo : je range pour l’instant ZF avec Pear dans les librairies. Symfony (et Jelyx :-p) sont des frameworks – mais après le terme fait débat … (ce n’est que mon avis)

    Merci à tous pour vos commentaires assez éclairant. Certains d’entre vous annoncent une grande flexibilité derrière le Zend Framework. Qu’est ce que cela veut dire ? Pourriez vous me donner un exemple permettant d’illustrer le concept ?

    merci par avance

    Répondre
  9. Philippe Le Van

    Bonjour,

    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.

    Répondre
  10. olivier

    Merci Philippe, je trouve la conclusion de ton commentaire très intéressante.

    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 !

    Répondre
  11. julienp

    Ce qui est sympa c’est de discuter entre frameworkiens.
    Par exemple à SolutionLinux, fin Janvier, je vais donner une conférence sur Zf juste après Fabien (Potencier) qui passe sur Symfony.
    On en profitera pour parlementer tout naturellement 🙂

    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.

    Répondre
  12. Yann

    @olivier:
    Il y a donc un système de plugin au niveau des controllers.

    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..

    Répondre
  13. Louis-Philippe Huberdeau

    J’ai utilisé le Zend Framework depuis le preview release 0.2. Je n’ai jamais regardé Symphony, alors mon point de comparaison est plutôt faible.

    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.

    Répondre
  14. olivier

    Merci à tous pour vos commentaires.

    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 😉

    Répondre
  15. Sylvio

    J’utilise Symfony (avec un ‘f’ et pas ‘ph’) depuis bientôt 2 ans. Je n’ai jamais testé ZF donc ce que je vais dire restent des impressions personnelles.

    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.

    Répondre
  16. Ping : Glagla Dot Org - Olivier Mansour » Pensez à intégrer Zend Framework dans votre framework habituel ?

  17. Emmanuel

    Bonjour,

    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)

    Répondre
  18. David

    bonjour, je suis en train de tester Zend

    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

    Répondre

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s