-
Notifications
You must be signed in to change notification settings - Fork 1
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
Comments
ok. |
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 : 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. |
C'est un formulaire simple alors parce que tu pouvais aussi mettre :
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. |
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). 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. |
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
The text was updated successfully, but these errors were encountered: