DutchBen
commented
1 week ago Open DutchBen opened 1 month ago
DutchBen
commented
1 week ago DutchBen
commented
1 week ago This document describes the minimum functionality SURF needs from a forms library. The goal of the
library is to transform a model that is defined on the backend as required input for a workflow into
a react form on the frontend. We are looking at the possibility to share this functionality as an open source
package so it can be used in contexts outside of SURF.
The package has 2 parts. The backend part that generates a JSONSchema and a frontend part that converts the schema into a html form
The current package we use is based on Uniforms. Uniforms handles the transformation from JSON to form fields. We have a list of basic fields, some wfo specific fields and some fields that implement very specific Surf logic.
The basic fields are:
The orchestrator core specific fields are:
The WFO Surf specific fields are:
Some fields depend on retrieving data after the field is loaded by making data calls. The SubscriptionField depends both on retrieving data and on the params passed to it in the form defintion.
For a future package we propose:
Open issues: Layout customization
... tbi ...
Mark90
commented
1 week ago Extending on this (note that this was a very rough idea without any certainty that it may work)
Implement a validation callback that can be called on every field value change. The return value from this call can be used to update the form defintion with data that can be used in other fields. We want to see if this way we can move all data retrieval to the backend
The "validation callback" here means doing the same POST call with form data that would be done on submit, but then upon changing a field (which could/should be restricted to fields of certain type, because this call may not be very fast if you are at formpage 10 for example) - or when pressing the 'reload' button near dropdowns (i.e. SubscriptionField).
This call would need to set a parameter in the body (validate_only: true or something) so that the pydantic-forms formgenerator only performs validations up until the last supplied formpage (perhaps without returning a "FormNotCompleteError" if the form is indeed valid, but maybe that doesn't matter)
We want to see if this way we can move all data retrieval to the backend
This obviously needs considerable changes to the backend forms and probably to the frontend components as well. The backend formpages would have to fetch all data needed for the dropdown, in a performant way.
The idea is that for dropdowns of which selecting a value has consequences for other fields,when a user selects a dropdown value, this will trigger the validation_only call so that the dependent field can be populated/enriched after calling the backend. For example in case of Surf's SubscriptionField; when selecting a subscription in the dropdown, currently the UI loads available vlans from IMS and adds them in the subtext of the vlan inputfield. In the proposed new situation, the subscription_id would be supplied as input to the backend call, which could somehow do this IMS call. (I'm not completely sure yet how this would work in the FormPage model though..)
2 challenges with that would be:
DutchBen
commented
6 days ago Ruben, Wouter, Mark, Tjeerd
Building on what was discussed and summarised above these considerations were added
Regarding configurable layourts whe have discussed
columns property to the form field definition that determines how many columns a field should take up in the grid.Possible next steps:
Get a list of requirements and ideas related to dynamic forms. This list will be used to compare with NCSC to see if there is enough common ground to create a separate open source project. Requirements include