Zend FR

Personnellement non, mais toutefois cela est réalisable à mon avis avec le viewscript. Ce n'est pas forcément évident à prendre en main, mais cela est assez puissant.

Je ne peux que te conseiller la doc officielle (http://framework.zend.com/manual/en/zen … iewScript, c'est la version anglaise car  la doc française sur cette page semble KO), si quelqu'un à un ou plusieurs tutos sur le sujet, n'hésitez pas.

Cordialement,

J'ai opté pour extjs mais je ne suis pas passé par PhpExt la raison est très simple toutes les approches qui consiste à généré le javascript en php sont porteuse d'un très gros handicap le code étant généré il est recompilé et ré interprété à chaque fois cela est très gourmands en bande passante et en temps d'interprétation.

J'ai donc opté pou une approche radicalement différente.
Php fournis à la vue une description structurelle de la vue (indépendante de la librairie utilisée) la vue contient un script qui va instancier les éléments de la vue à partir de la description.

le contrôleur fournis donc la description qui est un simple objet (soit html soit xml soit json) donc très peut de donnée seule cette petit partie sera recompilé ou ré interprété par le moteur JS. le script étant statique il est lui chargé une seule fois compile une seule fois et conservé en cache.

C'est donc beaucoup plus efficace.
de plus j'utilise a fond le fonctionnement d'EXT ainsi lorsque le contrôleur fournis une vue il ne fournis qu'une description de l'interface et l'adresse des actions fournissant les donnée. elle seront chargées en AJAX après l'affichage.

l'IHM apparait alors très dynamique.
cela permet aussi de maitriser la gestions du cache du navigateur ainsi lorsqu'un combo va chercher la liste des éléments à afficher si ce sont des données de références on peut les mettre en cache alors que les données du formulaire qui elle sont très dynamique n'ont pas à y aller.

de cette façon il devient facile d'optimiser le dialogue avec le serveur.

pour aller plus loin pour mes script statiques et uniquement eux j'utilise un packer de javascript il compacte le source en le conservant sous forme de texte. le source est débarrassé des commentaires et des espaces. il remplace les variable locale par des nom courts. cela optimise le transfert mais aussi l'interprétation. (Les compilateur javascript y sont sensibles)
toujours sur les js statiques j'utilise la compression gzip si le client le supporte. je place donc une version gzipé et une version normale sur le serveur.

je ne fais pas de compression à la volé trop couteuse en ressources système.

pour en revenir à ExtJS je trouve cette librairie riche facile d'abord et rapide. par contre je déplore des manque dans la doc. la description de l'API est bien faite. mais si tous les attribut son bien décrit il manque parfois d'explication pour expliquer comment les utiliser.
il y a de nombreux exemples mais là encore je suis septique. ils sont soit trop complexe soit trop simple.
en claire il sont trop complexe pour comprendre le B.A BA (pas tous mais certain sont opaques) et ils sont trop simple pour saisir les finalité.
l'exemple le plus frappant dans ce cas et le grid editor
c'est exemple contient un script plutôt évoluer et il faut un bout de temps à un débutant pour comprendre comment cela fonctionne. c'est exemple démontre comment on peut faire une tableau de donnée qui autorise l'édition directement dans les cellules avec champs de saisie combo datepicker etc. mais il n'y a absolument rien pour expliquer comment dans ce cas dialoguer avec le serveur. est-il possible d'envoyer les données à chaque changement de cellule ? comment poster les changement d'un row ? comment poster tous les changement d'un coup ? il n'y rien dans toute la doc pour ce genre de problématique.
c'est bien dommage car les capacité de la lib lorsqu'on commence à les maitriser font des merveilles.

pour finir par rapport à d'autre lib celle-ci est très homogène et c'est un vrais gain pour le développement. 

A+JYT