Replies: 4 comments 6 replies
-
This looks great. I know a lot of people will be happy about self-service forms.
Just inherit from the parent section (metadata)?
I'd say no for now.
It's a touch nerdy, but I think it's fine. If an author needs engineer help to setup a form, that's probably OK since the intake will also need to be validated. There will not be a lot of forms made... I hope.
I think this is an interesting one from a localization perspective. It calls out how we need DNT for rows / columns. I probably wouldn't do anything right now about this. |
Beta Was this translation helpful? Give feedback.
-
Thanks @elan-tbx , this looks great! Regarding the data collection part, I was wondering if you have considered the ability to post the collected data to an API endpoint instead? This would allow us to create RFI or trial forms where data needs to be ingested into external systems without us having to store the data whatsoever. |
Beta Was this translation helpful? Give feedback.
-
UpdateThe decision has been made to change the operator symbols for rule comparisons to standard math symbols (e.g., |
Beta Was this translation helpful? Give feedback.
-
UpdateTwo new operator symbols were added, |
Beta Was this translation helpful? Give feedback.
-
How It Works
At the direction of MWPW-139077, a new Form block is on the way. This differs from FaaS in that it allows authors to quickly put up simple forms with automatic data collection, based on the Franklin Forms architecture. All that is required is an Excel (or Google Sheets) document with some specific sheets and tables, and you should be ready to go.
The
helix-default
sheet, describing what the form should look like:The
incoming
sheet, where form submissions will be automatically collected (Note: the table here must be namedintake_form
. More details here:The Form block in use. The second row is just the path to your Excel document, followed by a
.json
file extension. The bottom row allows for a URL to redirect to after a successful form submission, or a simple Thank You message.The Form block on a page:
The currently supported field types are:
All form fields include a
required
option that is validated on submit. Beyond that, currently, default browser validation is used for the rest. Note that all fields are sanitized before submission.There also exists a basic "Rules" system for showing/hiding fields based on certain criteria. In the Excel doc used above, the last field before the buttons will have a
hidden
class applied iffavoriteNumber
is over 10:The
operator
strings used here are based onthe Python operator function namesstandard math symbols. Supported comparisons currently are:=
(equal)!=
(not equal)=
(equal)!=
(not equal)>
(greater than)>=
(greater than or equal to)<
(less than)<=
(less than or equal to)Purpose of Discussion
While there is a PR up for this first version of the block, I anticipate there will be many ideas/suggestions on how we can improve on this with future work. Do we want to add background-color/image support to the block? Should we include more stylized error messages for each field? How can the "Rules" system be improved upon? Are there other form inputs we should support?
Any and all input is greatly appreciated. Thanks.
Roadmap
Some ideas have been brought up for new features to put in the next version of the block:
I'll update this list as more feedback comes in
Beta Was this translation helpful? Give feedback.
All reactions