Discussion :

[rastaferraille]

Bonjour à tous,

Je me lance dans un nouveau projet et je me pose la question de savoir s'il est judicieux d'utiliser symfony avec la modelisation que j'ai choisie.
Je m'explique : j'ai besoin pour cette application de formulaires "dynamiques" qui varieront en fonction du choix de telle ou telle catégorie.

J'envisageais donc de stocker pour chaque catégorie en base une table "formulaire" liée à un ou plusieurs "champs" avec pour chacun un "type" (entier, texte, liste) et une liste de "valeurs" possibles (pour les listes déroulantes).

Ainsi, selon le choix que ferait l'internaute d'une catégorie, un formulaire différent lui serait affiché, généré dynamiquement et construit à partir des données en base de données.

Ce type de modélisation est il "compatible" avec symfony ?

[Michel Rotta]

Le formulaire est très souple et le formulaire est un objet.

Il y a, à mon avis deux possibilités.

Il est envisageable de créer des méthodes à actionner après l'initialisation du modèle (et donc l'appel de configure() ). Ces méthodes seraient appelée depuis le contrôleur pour modifier le fonctionnement de l'objet, rien n'oblige à limiter la création de widget et de validator à la méthode configure. En fait, il peuvent même être entièrement créé depuis l'extérieur de l'objet. Il doit donc être possible de créer les widget ET les validators qui vont bien.

[rastaferraille]

Salut, merci beaucoup pour ta réponse.

Je pense donc a une modelisation de ce genre :

Categorie ---> 1..* subform
subForm ---> 1..* subform
subForm ---> 1..* Widget
Widget --> 1..* Widget_Option
Widget_Option --> 1..* Widget_value


Widget_Option : id, name
Widget_value : id_widget_option, value

Qu'en penses tu ? ça te semble jouable ?

[Michel Rotta]

La base d'une application de gestion de données, c'est... les données.

Met donc ton schéma (config/doctrine/schema.yml) qu'on puisse jeter un oeil à la structure des données, une fois celle-ci validé, il sera temps de s'attaquer à la manière de les visualiser.

[rastaferraille]

ça roule, des que j'aurai fait le yml..

Merci du coup de main !

[rastaferraille]

Je me pose quand même une question : en admettant qu'on parvienne à générer les formulaires dynamiquement, comment enregistrer en base de données les valeurs saisies par les internautes ?

[Michel Rotta]

Heu...

méthode save() ?

Ben oui, c'est elle.

As-tu fais le tuto jobeet ? Au moins lu a fond ?

[rastaferraille]

Ce n'est pas ce que je veux dire. J'ai déjà développé une appli complète avec Symfony.

Je m'explique :

Admettons que nos formulaires soient générés dynamiquement en fonction des widgets saisis en base de données. Ils ne correspondront pas pour autant à un objet Doctrine, ou à une table de la base de données. Tu vois ce que je veux dire ?

Par exemple, si un utilisateur choisis la categorie 1, on va rechercher en base quels widgets instancier pour le formulaire correspondant à cette catégorie, comment seront sauvées les données saisies par l'internaute si ce formulaire ne correspond pas exactement à une table de la BD ?

Je ne sais pas si je suis clair...

[Michel Rotta]

Je vois assez bien, quoi que, chaque projet soit différent.

J'ai un truc en projet dans le même genre dans un coin de ma tête, une table en bout de liaison qui peut représenter des objets très différents les uns des autres. J'ai bien pensé mettre en place des tags sur la table.

Mais la table de tag serait beaucoup trop lourde en nombre d'enregistrement pour être gérable.

Donc l'idée que j'en ai maintenant (idée conceptuel, aucun test pour l'instant) est de mettre dans l'enregistrement du niveau précédant un string et d'y stocker un tableau ou un hash des données du niveau suivant.

Lors de la création du formulaire, en fonction du type de donnée, j'ouvre un form spécifique. L'avantage est que je suis limité en nombre de type (il devrait y en avoir plusieurs centaine), c'est moi qui définit le nombre, l'utilisateur n'a pas le choix.

Ensuite pour l'édition, il y aura deux formulaires, un pour les données communes, un pour les données spécifique. Formulaire spécifique, embarqué, la méthode bind et save réécrite pour que les données ne soient pas envoyée vers la base, mais vers la variable string en charge de les sauver.

Bon, c'est très conceptuel et je ne sais pas si cela va t'aider. Je n'ai pas encore écris la moindre ligne de code sur le projet, juste un bon début de cahier des charges.