modifier l'ordre des champs dans un module admin-generator

bonjour a tous,

voila toujours sous les modules générer par admin-generator

Aujourd'hui dans mon module j'ai une formulaire avec une autre (embedded form).

Dans le fichier generator.yml j'ai pu modifier l'ordre des champs du formulaire principale mais le problème est dans l'ordre des champs du formulaire imbriqué (embedded)

Vraiment j'ai cherché beaucoup dans le cache ainsi que dans generator.yml mais pas de solution.

alors qui connait ce genre des trucs ?

Merci

Ne t'occupe pas du génerator.yml.

Modifie l'ordre dans le form imbriqué...

Est-ce que tu as créés un module pour ce formulaire embriqué ? Si oui, si tu changes l'ordre des champs à partir du generator.yml ils le seront dans les deux cas.

oui , j'ai un module , et j'ai modifier le generator.yml mais ça change l'ordre des champs du formulaires principales (main) mais pas l'embeded form

Je te propose une solution. Créé un nouveau formulaire appellé XXXEmbedForm.class.php et qui étendra ton formulaire imbriqué.

Dedans tu ajoutes la méthode configure et tu peux faire quelque chose comme ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public function configure(){   parent::configure();   $this->widgetSchema->moveField('telephone', 'after', 'intitule'); $this->widgetSchema->moveField('adresse', 'after', 'telephone');   // etc...     }

---

Ensuite quand tu fais ton embedForm:

Code:

---

1 2	$new = new XXXEmbedForm(); $this->embedForm('new', $new);

---

Tu vois le principe ?
Sinon il y a le plugin ahDoctrineEasyEmbeddedRelations pour se simplifier la vie avec les embedform ;)

Dans un cas pareil, et sauf très forte relation avec le formulaire développé (par opposition au formulaire de base) je pense qu'il vaut mieux partir du formulaire de base.

Un exemple ? Un objet Client.
Le formulaire de base est :
lib/form/doctrine/base/BaseClientForm.class.php

Le formulaire développé est :
lib/form/doctrine/ClientForm.class.php

Pour le formulaire spécifique je recommanderais plutôt :
lib/form/doctrine/embedClientForm.class.php

Code:

---

1 2 3

class embedClientForm extand BaseClientForm ...

---

Ceci permet d'avoir toute latitude de modifier les différents formulaires sans risquer d'altérer l'un par la modification de l'autre.

bonjour , le problème c'est que je voudrais modifier l'ordre de champs de façon d'avoir un champs du main_form puis un champs de l'embeded_form puis un autre de main_form

donc y a pas un ordre main_form puis embeded_form
je voudrais mélanger les champs des deux form

je sais que très difficile , mais j'ai besoin de ce truc

:ccool:

Pour ce que tu proposes Mimi68 je ne suis pas totalement de ton avis, pour la raison que si dans mon formulaire j'ai redéfini par exemple des widget, mettre un textArea, ou un champs date tournant sous JQuery, je n'aurai pas à modifier à deux endroits différents si je décide que mon textArea devienne plutôt widget TyniMCE.

Sinon Fedora40, je ne sais pas si c'est possible, peut être mais long, car il y a bien le mergeForm qui pourrait faire ce que tu veux, mais la sauvegarde échouerait car il ne gère pas l'imbrication de formulaires. Il faudrait redéfinir une méthode avant la sauvegarde j'imagine.

On peut savoir ce que tu veux en faire au juste ? :mrgreen:

@skipe2 : tu as raison, c'est l'exception dont je parlais. Quoique, dans un pareil cas, je ferais (j'ai fais) 3 formulaires. Un parents avec les modifications a prendre dans le embed et le direct et deux autres form, un pour le embed et un pour le direct. Ainsi, les modifications du direct n'impacte pas l'embed et vis versa. Et les modifications générales sont bien prises en compte dans les deux form.


Tu peux, dans ton template, adresse chaque champs les uns après les autres et entièrement être maître de l'affichage. Cela marche très bien, sauf ... pour les modules admins. Quoique... Si tu redéfinis dans ton module un template, par défaut créé et défini dans le cache, c'est le fichier que tu as redéfini qui va être pris en compte. Tu peux donc réécrire le template et prendre celui-là en compte. Par contre, tu vas perdre une grande partie de la souplesse du générateur et toutes modification du generator.yml entrainera une modification manuel du template... On est loin de la souplesse. Il est peut-être plus simple, alors, de générer l'admin qui ressemble le plus à ce que tu veux, d'en récupérer le code dans le cache et de l'utiliser comme un module normal.