Several modules of Open Event Frontend involve the use of custom forms, which currently are not truly custom in the sense that they are really restricted, and rigid. Only text fields are available, along with hardcoded dropdowns. Further, the user is only able to select from among the hardcoded fields and toggle them on/off for his/her event.
Any component which extends the form mixin can make specify the validations required using the getValidationRules hook.
Current custom forms are really restricted, and rigid. Only text fields are available, along with hardcoded dropdowns. Further, the user is only able to select from among the hardcoded fields and toggle them on/off for his/her event.
We already have the framework to associate simple custom fields with individual events or orders, and an API to create them. The custom forms schema needs to be now expanded to allow more complex fields. Taking Google forms and our use case as an inspiration, the user should be able to create the following fields:
- Simple text *
- Paragraph *
- Radio Buttons (single choice)
- Checkboxes
- Dropdown
- File upload *
- Time
- Date
- Date & Time
* Already implemented
The schema needs expansion to accommodate options for fields like dropdowns, checkboxes and radio buttons. Also, to store custom labels to the fields, which the user assigns. Currently, they are hardcoded by comparing the name of the field with if-else.
Thus we propose the following schema related changes to accomodate the complex custom forms.
Add a separate model called customFormOptions to store various options of radio buttons, checkboxes, and dropdowns.
They will have the following fields:
| Column | Description |
| ID | default unique ID |
| value | value of the custom form field options like ‘XS, XL’ |
| custom_form_id | foreign key – the id of the custom form field this option belongs to |
CustomForm model will have a hasMany relationship with customFormOptions.
For text fields, and other fields which don’t require options within them can have the relationship as null.
The changes to customForm Model itself:
| Column | Description |
| description | An optional simple string column to store the custom messages/info the user may give to the custom form field like T-shirt Size Chart link etc. |
| isComplex | Boolean field to indicate if a particular field is complex |
The changes to event, speaker, session Models:
| Column | Description |
| customFormValues | A JSON type column which stores all the complex custom form values(currently all the fields offered are hardcoded in the schema) |
This expansion of schemas will allow the clients to create new, custom fields as per the requirement of the system. Future work may involve creating an API for validations of these fields.
Resources
- Jquery UI Calendar
- Moment js isAfter method
- Ember: using computed properties
- Semantic UI form Validation