Infos:

• Disabled : les data sont pas envoyés au submit
• Readonly : les data sont quand meme envoyés au submit

Est-ce qu'on garde ce fonctionnement ou l'on passe à readonly partout ?
A savoir, readonly n'existe pas pour les select.... on doit faire un disabled et mettre en hidden la valeur qui avait été sélectionné....

Bonjour,

Je fais un ticket un peu en "To Specify" par vos soin.

Je suis interesse par la solution mise en place aussi 👍

Si l'on veut sortir formidable en "libre" ou "open source" (a voir le licensing), un utilisateur de formidable aura envie d'utiliser ses propres JS pour gerer les datetime / date / autres fields.

Il serait bon de faire en sorte de rajouter un mechanism pour load les assets/statics via le built-in Django (a minima) ou autre si vous avez mieux:
https://docs.djangoproject.com/en/1.9/topics/forms/media/

Merci

Specification in progress

• Implement base validation CRUD
• Handle validation by field (all type of field does not accept all the validation type)
• Comparator Validation do not accept the type of value if the field is date or text or number.

Fonctionnalités identique au builder JS:

• Ajout/Suppression/Edition de champ
• Groupe de champs (itérable)
• Champs complexes
• Règles

Le tout programmable, par exemple :

...
form.addField('text')
...
A définir ~

• init du projet Django
• Mise en place du modèle

Lors de l'édition le front nous envoie le payload complet du nouveau form.

Il faut

• Mettre à jour les champs modifiés (Et leur dépendences [items, plus tard validation..])
• Supprimer les champs qui n'apparaissent plus
• Ajouter les nouveaux champs

Pour bien faire, il faut revoir ce qu'est la primary key d'un field (slug + foreign key du form), la clef primaire d'un item (key + foreign key du field) afin de se retrouver.

/!\ Attention, d'après le endpoint, l'id du form à mettre à jour est passé dans l'URL, pas dans le PayLoad Json.

Action de validation des data avant de submit un form.
Permet de récupérer les données d'erreurs sur les validations.

GET api/form/{id}/validate/

Payload: liste de clé valeur des champs

Return

Code 204 (NO CONTENT)

Tout va bien c'est valide ! \o/
Pas de contenu

Code 400

Liste des erreurs du formulaire selon https://github.com/peopledoc/people-kiki/wiki/API-Guidelines#messages-et-code-derreur

{
  "code": "validation_errors",
  "errors": [{
    "field": "name", 
    "code": "missing_field", 
    "message": "The field name is required."
  }, {
    [...]
  }]
}

The main idea is to provides a way to build dynamic or static list of choices inside a fields (dropdown, checkboxes, etc..).

You can imagine multiple source to generate those kind of lists.

• A plain text list push from the API (via front)
• A file uploaded containing the list
• Models from database

and so on !

The main objective is to maintain a list at one point (the list of the states in US for example) and use it in the fields. If the list contains an errors, we can edit it in one place not all the list is used.

Depuis un objet Formidable, il est utile de récupére un formulaire django associé.

>>> form = Formidable.objects.create(label='test', description=u'huge form')
>>> form.fields.create(type_id=u'text', slug='input-text', label=u'my text', required=True)
>>> drop = form.fields.create(type_id=u'dropdown', slug=u'weapon', label=u'your weapon', required=False)
>>> drop.items.objects.create(key=u'gun', value=u'eagle')

>>> django_form_class = form.to_django_form_class()
>>> django_form = django_form_class(data={'input-text': u'tutu', 'weapon': 'gin'})
>>> django_form.is_valid()
False
>>> django_form.errors
{'weapon': 'gin is not a valid choices'}
>>> django_form = django_form_class(data={'input-text': u'tutu', 'weapon': 'gun'})
>>> django_form.is_valid()
True

Add missing EmailField.

L'objectif est de fournir tout les outils, a partir d'un formulaire et d'un AST afin d'exécuter une validation fonctionnelle.

Les ordres des items dans les champs de sélection ne sont pas conservé.

Now a day , the python builder permits to create form through django form API. But, only creation.
The goal of this ticket is to enable form editing instead of creation only

API example

class MyForm(FormidableForm):
       first_name = fields.CharField()


form = MyForm.to_formidable(label=''create')

class MyForm(FormidableForm):
       first_name = fields.CharField()
       last_name = fields.CharField()

form = MyForm.to_formidable(instance=form)

>>> form.fields.filter(slug='last_name').exists()
True

Afin d'avoir une demo qui roxe ASAP, on merge la vue contextualise sans les tests (oui c'est mal, mais on attend que le builder python soit Ope t'entends !)

Donc la, y'a pas de tests sur la serialization contextualisees et c'est mal ! Du coup, faut le faire.

La plus part des objets nested dans un field sont gérer par un list serializer qui font globalement tout le temps la même chose.

Il y a du code à factoriser pour gérer les create/update/delete dans la méthode update

Pour rappel, tout le payloads final du form est transmit au back, c'est au back de gérer les opérations...

Lorsque l'on rajoute un radiobutton, l'ensemble des fields qui ont été rajouté avec n'est pas sauvagardé.

Je me retrouve à avoir des requêtes avec un code de retour 301

Pourvoir enregistrer des form/fields par API

• HelpText
  • Attribut help_text utilisé
  • Widget Markdown
• Title
  • Le titre est du texte brut et est stocké dans l'attribut "label"
  • Le widget de rendu peut prendre en paramètre une balise de rendu (h1, h2, h3..)
• Separator
  • Pas de texte particulier, par défaut la balise est affiché, peut-être configuré au niveau du widget

Access rights are hard coded and are define as string.

Define rights accesse as constants and if possible has integer.

Fields are naturally ordered in the listing (means no list on a side)

Today, the disabled attribute in input file is always filled with different value. "False" when the input is editable, "disabled" when the field is disabled. Fill the disabled attribute with any value has effect to disabled the field every time.

Do not set the "disabled" attribute when it's not needed.

Séparation Donnée/Logique

Chaque champs est représenté en base dans la table fields avec toutes les données disponibles pour chacun des fields. C'est à dire que la table contient tous les champs de bases des fields + les options disponibles pour chacun des types de fields.

on va retrouvé alors

label, helptext, default, type_id, placeholder, multiple, items

Chaque option n'a pas la même signification pour tel ou tel type de champs (Par exemple, les champs de type "text" n'ont que faire d'un items ou n'a pas à être "multiple"). Alors que c'est obligatoire pour un ChoiceField d'avoir cette liste items. Ou alors radioboxes est forcément "multiple=True". Le nombre de combinaisons de validations des options sont aussi nombreuses qu'il y a de type de champs.

Cela se fait déjà ressentir pour le payload attendu par l'UI d'édition. Le payload contient des clefs différentes en fonction du type de champs. Même si le client est très souple sur sa réception de données, il ne faut pas négliger les données à recevoir et à valider lors d'édition ou de création de champ dans un formulaire.

Pour le moment on ne parle que d'options dans un premier temps, mais très vite la validation par champ va pointer le bout de son nez. Et là, ça va devenir nettement plus compliqué à maintenir si on garde un serializer pour chaque type de champs.

Chaque Type de champs son sérializer.

Il faut arriver à produire un serializer spécifique à chaque type de champs pour y faire de la validation et de l'envoie de données le plus strict possible. En débrayant, on arrivera à "Contextualiser" les validations/serializations et aurevoir les IF à répétition.

Mais ce n'est pas si simple, lorsqu'on passe par les vues standard de rest-framework (RetrievieView), le serializers est souvent instancié sans intance. C'est lors de la génération des datas au final que l'instance est passé en paramètre

to_representation(self, instance)

Donc on ne sait qu'au dernier moment le type de champs que l'on est en train de rendre... Ce qui nous facilite pas vraiment la tâche.

Il semblerait que les méthodes , create et update soit similaire sur la mécanique, attention donc..

The serializer has been wrotten to create and update, but the view update is not implemented.

• app js standalone
• page de sélection du form voulu dans une liste qui amène à l'éditeur

Ajouter un vraie endpoint pour la récupération du form coté utilisateur api/form/:id
Aucun paramètre requis, le contexte (utilisateur loggé en général) doit fournir les infos nécessaire pour filter selon l'accès utilisateur.

Formidable runs tests against python 2 so far. Please add compatibility python3.

Définir des champs required/disabled dans l'API Crud ( égalemen dans les modèles par extension)

Par defaut, DRF jete une exception quand il y a une opération su un objet nested ne sachant pas comment le traiter (update, create ou delete ?)

Le comportement est le même pour l'update et le create,

• On dépile les data des objets nested
• On fait la mise à jour (ou création) du field
• On fait la mise à jour (ou création) des objets nested

Le code existant est défaillant en update lorsqu'il y a des objets validations, il faut en profiter pour refactoriser un peu ça.

• Mettre en place une methode pour que l'application cliente puisse fournir un jeu d'access (Settings, fonctions, etc)
• Mettre en place le end point qui liste l'ensemble des access
• Lier les accesses au fields d'un form

Est-ce qu'on utilise un format universel? ISO8601
Faire que la communication API soit sur le même format.

Fields:

• id (required)
• label (required)
• description

• API qui retourne les bons objets
• Respect de la doc : https://github.com/novapost/people-ask-specs/blob/formidable/formidable/README.md

Sous-tickets:

• Création Form #8
• List forms
• Get on form with details #6
• Update Form
• Delete Form

Some validations are available for a specific site for example, others are available for all the site define in the platform. We need to find way to contextualize available presets.