Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Priorité Modules #2

Open
extrablind opened this issue Feb 8, 2016 · 4 comments
Open

Priorité Modules #2

extrablind opened this issue Feb 8, 2016 · 4 comments

Comments

@extrablind
Copy link

La liste des modules a faire en priorité selon moi, qu'en dites vous ? (par ordre)

1 - Les clés : c'est usuel et facile à mettre en place, ca nous permettra de mettre en place une petite BDD
2 - Un outil de gestion des fabmanager (CRUD),
3 - Un module de gestion des formulaires global, via un champs sérializé par ex pour pouvoir faire plein de formulaires différents

@chrisnoisel
Copy link
Member

ok.
Attention pour les gestion de formulaire dynamique, je sens le dev d'un outils qui risque d'être plus gros que la création de formulaires indépendants.

@extrablind
Copy link
Author

Pas forcément, j'ai déjà fait ça, c'est relativement simple dans la mesure ou il n'y a pas de traitement du formulaire. La table ressemblerait à ça :
id -int - | fields - longtext - | type - varchar -

Où fields est un champs serializé de toutes les valeurs du form enregistré, qu'on peut désérialisé et exporter au besoin. Si on veut des entités particulières (ex : membres, fabmanagers...) il faudra les stocker à part.
Après il faut construire un template par formulaire.

@chrisnoisel
Copy link
Member

C'est un formulaire simple alors parce que tu pouvais aussi mettre :

  • des champs avec liste déroulante (donc des choix prédéfinis à mettre en base)
  • des cases à cocher
  • des champs conditionnels (suivant si tu as coché une case par ex)
  • des champs obligatoires
  • de la vérification de syntaxe (bon email / numéro de téléphone etc.)

Je capte pas l'intérêt de sérialiser des données en bdd, pour faire de l'import/export ok sinon je vois pas.

@extrablind
Copy link
Author

Le champs "fields" prête à confusion, il vaudrait dans ce cas mieux l'appeler "values". Ce champs sérialisé contiendrait toutes les données d'un formulaire validé envoyé à partir d'un template (donc qu'il faut coder avec ces petites mimines).
La validation des champs s'effectue au niveau de l'entité comme d'habitude.
Le champs type est en quelque sorte ce qui fera varier le template : member, satisfaction,... c'est le type de formulaire.
En effet, avec cette technique on a pas de champs conditionnel.

Si on ne fait pas comme ça on doit déclarer une entité par formulaire et donc une table contenant les champs pour chaque form. En soit rien de dérangeant, c'est juste plus long. Tout dépend de ce qu'on fait des datas : si on les exploite la seconde solution est mieux, si on les affiche la première sera plus rapide et pas forcément restrictive.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants