open-formulieren / open-forms Goto Github PK

Sven, please start implementing frontend code based on these designs (specific pages within Invision):

• DigiD login: https://projects.invisionapp.com/share/WFWG0ECKEXN#/screens/411174782
• Form details: https://projects.invisionapp.com/share/WFWG0ECKEXN#/screens/411174783, https://projects.invisionapp.com/share/WFWG0ECKEXN#/screens/411174787 and https://projects.invisionapp.com/share/WFWG0ECKEXN#/screens/411174786
• Errors: https://projects.invisionapp.com/share/WFWG0ECKEXN#/screens/412246767 and https://projects.invisionapp.com/share/WFWG0ECKEXN#/screens/412246768
• Overview: https://projects.invisionapp.com/share/WFWG0ECKEXN#/screens/411174788

Form builder

• Has checkbox element
• Has textfield element which allows regex validation for only letters (a-zA-Z)
• Has (implicit or not with other elements) label element
• Has custom element that is prefilled with an up-to-date (at time of rendering or retrieving form-definition) value of this API: http://worldtimeapi.org/api/timezone/Europe/Amsterdam.json (datetime-field)
• Other field elements should not be visible in the builder
• Build form of 1 text field that only shows (or is enabled) when the checkbox is checked. The textfield is then required.

Django stuff

• Form definition can be saved to database
• Form definition is exposed via API (or just a JSON-blob that was saved to the database)

Form renderer

• Form definition can be retrieved via API and rendered (shows checkbox and when checked, the textfield)
• Form is styled to look somewhat like the image below (ugly, but shows that we can style it).
• Form answers are printed to the console in JSON format

When submitting the form details, a "next step" should be shown to fill in user details.

The exact way to do this is up to the dev. Note that @svenvandescheur is probably needed for some frontend stuff.

There should be a container model to hold form meta data (and ofcourse the form definition itself).

For now, a form should have:

• name (required)
• slug (auto, required)

...on top of the generic design.

Currently, we're missing the mobile version. This is being done by Roxanne.

Start with the default project, add or enable admin-index

Form builder

• Has checkbox element
• Has textfield element which allows regex validation for only letters (a-zA-Z)
• Has (implicit or not with other elements) label element
• Has custom element that is prefilled with an up-to-date (at time of rendering or retrieving form-definition) value of this API: http://worldtimeapi.org/api/timezone/Europe/Amsterdam.json (datetime-field)
• Other field elements should not be visible in the builder
• Build form of 1 text field that only shows (or is enabled) when the checkbox is checked. The textfield is then required.

Django stuff

• Form definition can be saved to database
• Form definition is exposed via API (or just a JSON-blob that was saved to the database)

Form renderer

• Form definition can be retrieved via API and rendered (shows checkbox and when checked, the textfield)
• Form is styled to look somewhat like the image below (ugly, but shows we can style it).
• Form answers are printed to the console in JSON format

A form instance should optionally relate to a product.

The prototype is currently running at Utrecht

Alternatives can be considered but I specifically want FormIO to be analysed. It offers a JS-powered form builder app and a JS-lib for rendering forms created with that builder. See builder: https://codepen.io/travist/full/xVyMjo/ and rendering: https://formio.github.io/formio.js/ Also, there's an existing investigation from a while ago that might be related: cityofaustin/techstack#303

Requirements

A form-library...

• needs to be open source
• allow free commercial use
• allow extensions / custom elements (whether they need to be open source or not)
• fill in one or more (partial) project architecture components, like:
  • Form builder (build forms can be saved as a form definition)
  • Form renderer (forms can be rendered based on a form definition)
• is well documented
• saves us time developing open forms
• does not conflict with project goals (for example: if the library prohibits us from saving data, its not suitable for us)

Now, there are a few requirements in this project that might not be filled in by the library. The question is if we can add them easily. Examples are:

• Form fields can depend on eachother
• Form fields can have (regex) validation
• Forms can be prefilled
• FormWizards can be created (ie. multiple pages of forms)

In #1 it was decided w'll use Form.IO. The builder part should be integrated in the admin.

Example:

We need a simple model to manage products. There is a component for this but we're leaving that out of scope for now. The component is typically called PDC: "Producten en Diensten Catalogus".

The model can contain only 3 fields for now:

• name (required)
• url (optional, to product details in a PDC)
• price (decimal field, optional)

Make sure the model is editable in the admin.

Simple pulldown with options should be able to add:

The form we're creating now will feature 3 elements. First element is a radiobutton list.

In our form instance, this is used for the "category".

Using #19 and #20, the category selection should change the pulldown options in the reason pulldown: