Multiple Form Instances associated with one task

1

Hi,

Many of the java Form Engine API’s seem geared towards a single instance of a form per task (like completeTaskWithForm). I guess this makes sense in that variables may clash if you were to store them on the process engine, but what if the form data was rather stored as objects in themselves through which data can be reference?

It seems to me to at least be theoretically possible to store multiple instances associated with a task in the database. So if I had 2 instances of form x for one task I would have something like this in the database:

act_fo_form_resource
                 id_                  |             resource_bytes_ 
--------------------------------------+------------------------------
 ef3934f3-6650-11e7-8866-024264d65c63 | {"values":{"var1":"hello"}}
 e91ca7d1-42c1-11e7-872a-02420b015a3f | {"values":{"var1":"bye"}}


act_fo_form_instance
                 id_                  |         form_definition_id_          | task_id_ |           form_values_id_            
--------------------------------------+--------------------------------------+----------+--------------------------------------
 ef398314-6650-11e7-8866-024264d65c63 | cf036bb3-64b7-11e7-bc13-024264d65c63 | 174      | ef3934f3-6650-11e7-8866-024264d65c63
 e91ccee2-42c1-11e7-872a-02420b015a3f | cf036bb3-64b7-11e7-bc13-024264d65c63 | 174      | e91ca7d1-42c1-11e7-872a-02420b015a3f

Task 174 having multiple instances of form definition cf036bb3-64b7-11e7-bc13-024264d65c63.

Is this an acceptable approach? I don’t want to stray too far from the intention of the authors here.

I have a use case where someone loads up a CSV file, that contains multiple instances of a form, which a user then gets back as a form to review and edit. While I could use form_key and roll my own forms, I want to see how much mileage I can get out of the form engine.

Another option is to have multiple task instances each with their own form instances, but from a modelling perspective this makes me uneasy and generates extra overhead.

Any comments? Ideas?

1 Like
2

I believe in theory, yes, from a quick glimpse at the code (but haven’t tried it).
You wouldn’t be able to use the out of the box UI’s though as they have a different assumption.

I’m not sure I’m following the use case fully yet, but aren’t you looking for a wizard style of form or a form with multiple pages (both which are currently not in there)?

1 Like
3

Thanks for the reply Joram, I understand the limitation on the out of the box UI’s, and I am building a completely custom UI so that is not a particular problem for me. But at the same time I am looking at potential enhancements of the flowable form engine, so that I don’t just roll my own for complex forms, but be able to contribute back as well, if we are aligned.

The CSV upload use case, basically involves an excel file generated by another application which contains a specification of a items to be manufactured, each column is an item and each row a field. Ideally I want to render this as a table similar to the spreadsheet with editable fields, but I may want to render it differently in another context, such as the wizard/pages examples you used.

eg.
ITEM,item1,alt item1, item2, alt item2
pressure, 5600, 5600, 6785, 6785
flow rate, 12.2, 12.2, 18, 18

From my perspective the above are 4 instances of a form specification, all filled in as the same task “Review specification”. But I don’t want to exclude the option of someone adding another item from scratch to that specification during review. Also I am thinking beyond this specific use case to the general case.

Note that in this case they actually end up on the same quote which means they could be stored in the same form instance.

So I see a few options, some of which require changes to the form engine:

  1. Multiple instances of the same form on the same task, stored as separate form instances. Looks like no changes required to engine.
  2. Multiple instances of the same form on the same task, stored in the same form instance.
  3. Introduce the concept of a subform field, so that a master form could have a reference to another form, one could specify the cardinality, such that it may be an unbounded number. There are two choices for the storage, store the data as separate form instances (like option 1 above) where the subform field itselfs rendered in the main instance as the form instance id, or store the subform data as a nested json object.

The subform idea is one that is growing on me, but would require more time to implement. I will soon have a bit of time to work on something like that.

I noticed two field types in different parts of the code that I am unsure about how they are used or intended to be used

  1. There is a CONTAINER field in FormFieldTypes, but don’t see it as an option in the form editor. Is this meant for some section like a disclosure panel? Doesn’t look like it can handle cardinality.
  2. It looks almost like there is a dynamic-table field type in use in “flowable-ui-admin/src/main/webapp/views/field-preview-template.html”, but I don’t really know angular so I am not 100% sure if this is even a field type, as I don’t see code to save its data in the form values:
1 Like
4

That’s quite a bit of text :wink:

Reading through your use case again, that’s indeed currently not possible with current form editor and engine. I think your option with subforms will work, but it’s constrained to this use case with tabular data where you have a master form and then subforms for various details.

Wouldn’t a more generic wizard-style approach work better (like formA -> formB -> formB, all within the same user task … but of course then the question whether or not the form should be saved intermediary comes to mind … maybe a master/sub form does make this easer)? Data in forms is not necessarily related to a ‘master form’. Or what’s the driving idea behind having a master form?

Anyway, just some random ideas :wink:

5

Yeah sorry about all that text :slight_smile:

The wizards approach is useful generally, but would have usability issues for my current use case. I’ll give some more thought to your comments…

My interim solution is to create a FormModel dynamically, using a FormContainer field to represent the table and store it in a process variable as json (due to form field serialization issue, I sent a pull request to fix it). When my UI asks for a task form I check for the presence of this variable and then return that as the FormModel.

I could store this FormModel as a standard form model during this process, but I have to think through the effect this proliferation of models would have where each has only one form instance, and especially on the UI of the modeler app.