[sf 1.4.x] surcharge admin générator champs cle etrangere [Résolu]

[mantex]

Bonjour,

J'ai surchargé un formulaire de l' admin generator d' un des modules, mais je souhaiterai fixé un champs du formulaire qui actuellement propose une liste à l' utilisateur.

Par exemple en cachant ce champs avec un input hidden et un setMonchamps('valeurdynamique') dans le contrôleur.

Le cas présent est différent car je surcharge le formulaire new de l'admin generator.

En plus l' idée est que cette modif ne soit pas valide dans mon module admin qui lui a besoin de disposer d' une liste pour ce champs. et donc seulement dans la partie surchargée.


J'ai cherché du coté du generator.yml mais rien de bien convaincant.

[Michel Rotta]

Il m'est avis que ...

... je ne comprend rien à ce que tu souhaites.

Je te propose donc de reformuler ta question.

Un exemple de ce qu'un utilisateur doit faire pourrait aider.

[mantex]

OK .. je m' en doutais c'est tout simple mais pas facile à expliquer clairement en une fois..

Je reprends..

J' ai un formulaire admin que je surcharge donc il me fait le lien automatiquement avec les autres tables notamment sur un champs 'customer_id'.

Cela est intéressant dans un usage admin, mais quand c ' un client X qui l' utilise. Celui ci ne doit pas voir les autres éléments de la liste du champs customer_id et le champs doit être rempli avec l' id du user qui est connecté par exemple.

Est ce plus clair ?

[mantex]

Bonjour à tous,

J' ai finalement résolu mon problème en héritant la classe Contributor généré par le admin générator, ce qui m' a permis de crée un formulaire de base dans cette classe et donc de gérer comme je le souhaite ma clé étrangère ainsi que le template.

Dernier point, existe t-il un moyen pour personnaliser les champs du formulaire sans les modifier directement dans le template ?

[insane1]

Qu'appelle tu personaliser ?
Pour changer les label à coté des champs de ton formulaire, ça se passe dans le generator.yml
Sinon pour modifier les champs eux même va voir le form concerné.

[mantex]

Par exemple pour ne pas avoir une liste déroulante sur une clé étrangère mais juste la valeur de l' utilisateur qui est connecté.

Les admin générator c' est bien mais dés le module doit être partiellement utilisé par des utilisateurs simple, Ca devient vite embettant.

j' ai donc hérité ma classe pour ne pas avoir à les contraintes de l' admin générator et par soucll d' indépendance.

Car la classe est utilisée aussi bien par des admin que par les clients qui ont juste le droit de modifier ce qui les concernent.

Ensuite pour personnaliser les labels de mes champs j' ai utilisé la fonction setLabel() dans ma nouvelle classe NouelleClasseForm.

Merci quand même.

[Michel Rotta]

Envoyé par mantex

Est ce plus clair ?

Je vais commander du paracétamol.

Je ne sais pas comment tu as réellement résolu, attention si tu fais transiter l'information dans un champ caché du formulaire, il reste modifiable facilement par un utilisateur averti et mal intentionné

@insane1 le générator.yml ne permettra de modifier que si tu as générer un module d'administration, ce qui ne semble pas le cas ici.

Je pense qu'il vaut mieux faire deux modules, un pour l'administration, un pour les utilisateurs, bien ; plutôt que de tenter de n'en faire qu'un, mal.

Le mieux est de passer par le parameterHolder de l'objet sfUser pour transmettre une donnée masquée et qui ne doit pas être modifiée. Surtout si c'est l'id de l'utilisateur, qui devrait déjà y figurer.

[mantex]

Envoyé par Michel Rotta

Je vais commander du paracétamol.

@insane1 le générator.yml ne permettra de modifier que si tu as générer un module d'administration, ce qui ne semble pas le cas ici.

Tout à fait..

Je pense qu'il vaut mieux faire deux modules, un pour l'administration, un pour les utilisateurs, bien ; plutôt que de tenter de n'en faire qu'un, mal.

et le principe de dry ? ;-) surtout pour 1 seul formulaire..

[Michel Rotta]

Les deux formulaires ont des destinations différentes.

Il reste possible (souhaitable) de partir d'un même form, qui, par l'héritage, pourra être facilement adapté avec le code spécifique à chaque module. De même, le code de traitement des objets du modèle sera partagé à partir de ces mêmes objets du modèle.

En fait, seul le code réellement très spécifique à chaque module sera propre à chaque module et le DRY se portera bien