Zend FR

Salut, as-tu vraiment besoin de tester le type de $isBase ?? parce que pour ton test if (!$isBase) { ... } suffirait .

Salut,

pfouuu !
Gros mélange deux noeud hard core Hevy brek bits man !

En faite:
j'ai fait des fieldset de test qui s'imbrique, mais je l'ai fait un peut trop à la rache, avec certain qui appel d'autre déjà appeler plus haut, bref, je ne sais pas ou j'ai fait un noeud mais sa la fait plané a 15 000. J'arrivai même pas a voir le résultat d'un echo...(dailleur comment est-ce possible?)

J'ai fini par refaire une hiérarchie plus propre pour tester tout autre chose en attendant votre aide et paf, maintenant que je réessaye, changer la condition me change bien le résultat x) (comme quoi faut soigné ses environnement de test xD )

En revanche il semblerai que la propriété privé $wrapper ne sois appeler qu'a la toute toute fin, une seul foi, alors que la méthode render s'exécute pour chaque fieldset de la hiérarchie, et cela bien en amont, du coup, $wrapper prendra la valeur du dernier fieldset...pour tout les fieldset >.<
 
Se qui nous amène a la question suivante:

-> Mais ou c'est donc que c'est que la méthode getWrapper est appeler, dit donc? comprend pas encore bien comment sa marche les aide de vue moi.

Par contre tout autre chose qui pourrai faire l'objet d'un autre topic:

-> Je pensais que si on m'était l'options "use_as_base_fieldset" à vrai à l'ajout d'un fieldset dans un autre fieldset, quelque chose comme:

<input name="form[parentFieldset][childFieldset][field01]" /> deviendrait -> <input name="form[parentFieldset][field01]" />

Mais non, sa marche pôs -.-

le set_as_base_fieldset n'est utilisé qu'au niveau du formulaire? si oui, comment faire dans mon cas? (doit-je ouvrir un nouveau topic? ^) Me dite pas que c'est pas possible car je viens de basé toute une méthodologie la dessus ^^ (pour la génération du DOM, la gestion des ValidationGroupe(), ect)

, as-tu vraiment besoin de tester le type de $isBase ?? parce que pour ton test if (!$isBase) { ... }  } suffirait wink.

Je sais bien, mais c'était pour être certain que $isBase n'était pas égal a NULL ou a 0 ou a une chaine vide, ce qui aurai pue expliquer pourquoi j'avais toujours le même résultat

Dernière modification par Splyf (15-04-2014 18:55:09)

Bonjour,

Donc sa veut dire que une entité => 1 seul field set? pas moyen de le découper en plusieurs?
Prenons un exemple: 

Une table dont une partie des champs peut être vue et édité par un type d'utilisateurs, une autre partie par un autre type d’utilisateurs, puis un 3eme type d'utilisateurs(un admin au hasard ^^) qui peut éditer les deux parties...pour ce dernier je doit refaire un 3eme fieldset?? j'aimerai pouvoir faire un 3eme fiedset mais qui à comme élément les deux autres.
Ceci est un exemple mais je peut en trouver plein d'autre, pense tu que c'est une erreur de conceptions ? (ou est-je encore raté quelque chose ?)

Pas possible? Ou alors je doit passé par d'autre classe, qui ne sont pas des fieldset ni des élément mais qui me retournerai les tableau de donné pour construire les champs? bof bof :s

Ce que je ne comprend pas dans l'aide de vue, dans le cas du formCollection par exemple, on a la methode render() qui construit la chaine, mais pas la totalité de la chaine, je ne vois getWrapper() null part et c'est lui qui retourne la string contenant le <fieldset>%s</fieldset>.
Il y a une autre classe qui gère l'affichage de formCollection?

EDIT : autre exemple:
Admétons une table etablissements, contenant description, adresse, caractèristique
Une table restaurant comprend des caractèristique suplémentaire, et hérite de établissement.
Je veut regrouper les caractéristiques de la partie établissement(ex: accept_CB, accept_chequeVac) et de la partie restaurant (ex: acces_handicape, acces_wifi,ect) en un seul fieldset à part, pour deux raison:
- je veut qu'au niveau du DOM, les champs correspondant au caractéristique des deux tables sois regroupe dans le même <fieldset>, sans avoir besoin de réécrire ->formRow('element') pour chaque element simpelement pour une simple réorganisation, alors qu on pourrai ainsi écrire un seul et unique formCollection avec cette solution
- Je veut simplifier au max l'utilisation du validationGroup(). Avec cette solution, je ne suis pas oblité de réécrire tout les champs alors qu'il n'y en a qu'un seul que je ne veut plus validé...

Ainsi, je peut faire un fieldset "caracterisitiqueEtablissement" et un caracteristiqueRestau", puis je les regroupe dans un autre, ou j'en prend un, ou l'autre, ect me permetant ainsi de controller aisément mes champ par groupe, au lieu de créer 10 000 fieldset

Dernière modification par Splyf (16-04-2014 10:10:59)

woua ok, grosse erreur de conception en effet.
En faite je l'avais bien comprise mais sa m'embêtai tellement de réecrire toute la vue avec des formRow plutôt qu'un simple "formCollection", simplement pour réorganisé le dom que je me suis empressé de tout oublié xD

et puis si j'utilise un même formulaire dans plusieurs vue, je voullai évité d'avoir a repassé sur tout a l'ajout / modification / supression de champ...mais du coup je suppose qu'il faille que je me tourne toute bêtement sur les vue partiel x).

Bon,je revois ma conception (heureusement que je fait des essais avant de fonçer tête baissé, c'est pour refondre un gros projet d'envergure! )

Edit:
Pour les validations groupe, si dans une vue je n'ai qu'un seul champs en moins du formulaire, pour le moment je fait sa dans le controller:

$form->setValidationGroup([
champ1, champs2, champ3,[fsChamp1.1, fsChamp1.2]
])

Je trouve sa très lourd, surtout pour la maintenance ! comment dire simplement "validé tout sauf le champ x ?"

Dernière modification par Splyf (16-04-2014 11:19:44)

heu oui pardon j'ai pas relut et pas encore l'abitude c'était juste pour imager mon propo ^^

Bon ok!

Pour être d'avoir bien compris:
jai une vue a avec tout les champ dun fieldset, je fait un formulaire A
jai une autre vue avec quelque champ en moins dun fieldset, je fait un formulaire B?

en création de compte tu vas t'assurer que le login et le mail n'existent pas déjà alors qu'en mise à jour tu t'assures qu'ils sont unique

Tu veut dire que pour un update et un insert, tu creer deux formulaire différent?
Sa devient pas un peut lourd pour la maintenance après?

Dans un avenir assez proche le projet en question va évoluer très rapidement, (d'ou le choix de le refondre sur un framework mvc solide ^^) et je veut réduire un max les taches a chaque ajout / supression d'un champ dans la bdd

Mhhhhh,Dans ce cas:
(pas taper si c'est du grand n'importe quoi je début en MVC ^^ )

dans le formulaire on rajoute une variable $mode, par default sur "INSERT"
a l'insertion:

$form = new App\Form\MyForm('UPDATE' )
puis dans le formulaire, selon la valeur de $mode, on ajoute ou pas un élément, on choisi tel ou tel validateur, ce qui nous permet ainsi de n'écrire qu'une foi pour toute la définition d'un champ !!

Par contre, je ne sais pas encore comment faire avec le FormManager, peut on lui dire de passé des paramêtre lorsqu'il initie un formulaire, ou qu'il appelle la méthode init() ?

(--> factory? )

Mhhhh okay!

dans le cas d'un formuaire qui a 20 champ et qui na comme seul différence entre l'insert et l'update qu'une ou deux validateur, je pense que cest quand meme plus simple pour la maintenance de passé par les fabrique :p

merci en tout cas pas mal de chose son devenu bien plus clair!