Feature explanation from the PRD doc made by Tarek:
Dynamic forms:
In some forms (e.g., Bakery’s Order form), several items are added to the form by the user clicking on something like an “add” button. The API should enable the programmer an easy way to add several items to this kind of form based on the reply from ChatGPT.
We discussed on today's daily with @mgarciavaadin and @mshabarov that the feature is feasible, and we see the following way to do it right now after some hours of investigation and tech discussions:
Problematic parts:
how to mark dynamic parts of the form (should we find out algorithmically, or ask the customer to mark them with an id/label/tooltip)
how to make sure the dynamic parts are added correctly to the form the way the customer would like, and nicely designed,
Change the internal part of the Form Filler to support forms within forms and support the filling for those layouts.
Extending the FormFiller API with a new method potential naming could be AutoFormFiller::aaddDymanicForm() or AutoFormFiller::addDynamicComponents()
The new method would ask for the component and the callback arguments (AutoFormFiller::addDynamicComponents(verticalLayout, callback),
where the component would be the layout for the dynamic part of the form,
and the callback is a method, which would describe, how we would need to add the response components (in a different div or a layout? or different order of the components?)
Then similarly to the Grid we would be able to match the response JSON lists with the components and fill one by one them.
As of right now ComponentUtils and FormFiller classes are handling components and not layouts for fills (big if-else part), We need to refactor and change quite many parts of the code and further investigation is needed how complex is this change.
+1) Potentially as we had this proposal, we could solve this without introducing a new API method, but in that case, we would need to have some assumptions for example:
a layout within the layout is always a dynamic part,
potentially mark the components other way with a dynamic post or prefix (e.g. setId("name-dynamic"))
just multiplying the components without a callback first,
+2) We also brought up the topic of a fully dynamically generated form/components from a text:
Technically with maybe ~2 calls to the LLM is solvable,
but we see some complexity/issuse to saving it to RDBMS, probably saving to document storage or visualizing the data would be the potential use case of this.
Feature explanation from the PRD doc made by Tarek:
We discussed on today's daily with @mgarciavaadin and @mshabarov that the feature is feasible, and we see the following way to do it right now after some hours of investigation and tech discussions:
Problematic parts:
Extending the FormFiller API with a new method potential naming could be
AutoFormFiller::aaddDymanicForm()orAutoFormFiller::addDynamicComponents()The new method would ask for the component and the callback arguments (
AutoFormFiller::addDynamicComponents(verticalLayout, callback),componentwould be the layout for the dynamic part of the form,callbackis a method, which would describe, how we would need to add the response components (in a different div or a layout? or different order of the components?)Then similarly to the Grid we would be able to match the response JSON lists with the components and fill one by one them.
As of right now
ComponentUtilsandFormFillerclasses are handling components and not layouts for fills (big if-else part), We need to refactor and change quite many parts of the code and further investigation is needed how complex is this change.+1) Potentially as we had this proposal, we could solve this without introducing a new API method, but in that case, we would need to have some assumptions for example:
setId("name-dynamic"))This is a big question of coding convention over configuration
+2) We also brought up the topic of a fully dynamically generated form/components from a text: