Zend FR

ok merci pour l'info.
Je pense que le soucis venait du fait qu'il y avait un isValid($postData) plus bas => il réaffectait les postData au formulaire.

Du coup y a t il un moyen de faire un isValid en lui demandant de ne pas réaffecter les données ?

Merci

C'est quand même bizarre comme raisonnement :
Valider un formulaire non rempli...

Je suis d'accord avec MoOx pour le fonctionnement.

En fait je suis surtout sur un exercice de style concernant le Zend Framework :
Je suis parti du postulat qu'il y a souvent dans une base de donnée des tables qui n'ont que 2 champs (id/label).  Ces tables permettent de gérer des listes facilement éditable via l'administrateur. Je voulais donc faire un CRUD sur ces tables en automatisant au maximum le process et qui puisse être utilisé dans différent comportement d'ergonomie :
   1 -> on affiche la liste des tables concernées -> on choisi la table -> on réaffiche la page en gardant le premier formulaire + le nouveau formulaire d'ajout + la liste du contenu de la table sélectionné, liste qui permet d'éditer ou supprimer un item => on se retrouve avec plusieurs formulaires
   2 -> on affiche la liste des tables concernées -> on choisi la table -> on part sur le formulaire d'ajout => on a un seul formulaire à chaque fois
   3 -> on par sur le même principe que 1 mais au lieu de rafraichir on utilise Ajax

Les contraintes sont donc importantes :
dans 1 on doit identifier en permanence quel formulaire a été posté (s'il y a eu post)
il doit y avoir une action principale qui se charge d'appeler les autres actions
ces autres actions doivent également pouvoir fonctionner en solo (mode Ajax ou refresh)
on doit pouvoir charger un formulaire et un modèle différent selon le premier choix effectué
on doit pouvoir identifier le nom de la clé primaire si on est dans un système où la convention n'existe pas (cas choisi par ZendF)

Après quelques jours de travail sur cet exercice où j'ai regardé en profondeur Zend_Controller, Zend_Form, Zend_Db_Table, et où mon bout d'appli fonctionne bien, je peux dire :
que ZendF est vraiment lourd par rapport à un copix par exemple
que le Zend_Tool est vraiment riquiqui par rapport à un symfony (pas de génération auto des formulaires ni même des modèles)
que Zend_Db_Table n'est pas pratique pour faire de l'édition ou de la suppression puisque l'on est obligé de générer la partie Where de la requete => obligation de surcharger soi-même pour limiter cette contrainte
que Zend_Form est facile à utiliser avec un formulaire, mais pas avec plusieurs => obligation de surcharger pour mettre ce type de mécanisme en place
que ZendF n'est pas assez directif pour être certains que ses développeurs codent bien tous de la même manière.
qu'il faut donc surcharger beaucoup de classe pour arriver à ses fins, sans garanties que l'on fasse les bons choix (bonne pratique, performance, ...)

C'est une bonne îdée de module pour Zend, ça me plait ;-)

ZendF comme boite à outil : effectivement je m'en suis déjà servi comme ça pour plein de projet, mais PEAR (que je n'ai jamais apprécié) faisais déjà la même chose (mais sans l'appui de Zend, oui j'en suis conscient).

Zend_Db_Table_Row : je vais y jeter un coup d'oeil plus sérieusement, à la première lecture, ça peut être intéressant et se rapprocher d'un système de DAO

Surcharge = secret de la POO : pas tout à fait, c'est un des éléments de la POO. A partir de là, si je dois surcharger toutes les classes du framework pour atteindre mon but, c'est que le framework est certes étendable à souhait, mais surtout il ne répond pas à mes attentes et m'oblige à faire une surcharge de Framework pour avoir en avoir un utilisable et fournissant toute les fonctionnalités à mes développeurs => myFramework extends ZendFramework, bah dégueu et soucis liés aux évolutions du framework de base. Mais bon c'est un choix.

Tout à fait d'accord avec toi, un framework est là pour nous aider, pas pour faire les tâches à notre place. Maintenant si je dois me poser plein de question quant à la manière d'utiliser le framework Zend, c'est que ce dernier ne nous aide pas tant que ça. Quand on lit la doc d'un framework on doit être capable de monter son application rapidement. C'est le cas avec Copix, Jelix, Symfony et plein d'autres. Maintenant pour faire un CRUD avec Zend, il n'y a rien d'officiel, et sur le web, vous n'en trouvez pas un seul qui se ressemble (logique d'implémentation différente, Fat Controller, erreur de conception, utilisation de Zend_Db mais pas de Zend_Db_Table, Pas de Zend_Form, surcharge multiple des classes de base... ).

Contrairement à toi, je considère qu'un framework doit aussi nous guider. Dailleurs ZendF nous dit bien comment on doit nommer nos classes et les stocker dans l'arborescence. Le problème avec ZendF se situe surtout au niveau du MVC. Pour le reste, ça reste une très bonne librairie, mais pour le MVC, à nous laisser trop de liberté, on voit fleurir n'importe quoi à droite ou à gauche. Il y a aussi, et heureusement de très bonne chose, mais contrairement à un framework plus directif ou la convention prend le pas sur la configuration, on voit beaucoup plus de déchet.

Pour les choix d'archi et de performance, évidemment que le framework peut nous orienter, et heureusement, sinon pourquoi y aurait il autant de bench comparant les frameworks pour une fonctionnalité donnée.

J'espère que ZendF deviendra un bon framework car il en va du futur de PHP et de sa crédibilité en entreprise. Je suis aussi conscient que beaucoup d'entreprise cherche des développeurs avec des compétences sur ZendF, mais aujourd'hui, j'ai toujours un doute sur le fait de partir avec ce framework. A laisser trop libre les développeur/analyste programmeur/ingénieur/consultant, on risque d'obtenir un projet difficilement maintenable au bout de quelques mois/années.