I often wished for the following behavior in forms, because in my opinion it’s best for usability.
So I was glad, when the same requirement came up in our current A12 training, because their in-house UX style guide requires it, too:
When a part of the form gets hidden (based on some trigger field), then
- the values of the hidden form should not be cleared immediately, so that when the user toggles the trigger field again (so that the hidden fields get visible again), the values are still present.
This allows for a more exploratory usage, without having to fear that entered data gets lost.
- However, when the form gets saved all fields’ values that are hidden (because of a dependency) should get cleared. This avoids confusion on the server-side because it does not store values that are actually unused.
I suppose this is not possible by default. Should I create a ticket?
Also, what would be the best way to implement that in a project?
From a UX standpoint this looks like a reasonable approach. But from a server side view the backend should know nothing about what parts of a form are hidden or not depending on some field values and hence should not modify a submitted document in any way.
Other points to consider are forms spanning multiple screens/tabs/or whatever. In such cases fields should never be cleared. And what about inline repeats that get hidden?
So from my point of view the best course of action would be to implement this client side only. On submit go through the form model and determine for every control if it is hidden. If it is clear the field the control references. Then validate once again to be sure that you hadn’t missed a field dependency in a validation rule that isn’t modeled correctly in your form. And be prepared to have a workaround for the user if such a situation is encountered.
Also remember that from a server side perspective there is no such thing as “unused fields” since the submitted document is valid. So to be sure to not have such fields you have to explicitly create validation rules that specify that fields must be empty based on some condition. Note however that such a validation rule would be conflicting with your desired form model behaviour to not clear fields that are currently hidden.
I never implied to do that on the server side.
Also I don’t talk about “hidden” in the sense of “currently not visible because on a different screen”.
I am talking about explicitly defined dependent groups/fields in the form model.
The client part of the form engine knows when it sends a document for saving, so it could handle that “clear-on-save” dependency action, right?
Hi Stephen,
TLDR: I would say it would be a useful feature. I am not sure if others see this as important enough, though and I can’t tell you if it is going to be implemented soon (we have to estimate it first, maybe it has some complications, see below).
Long story.
I agree that it would be better to keep values of fields hidden by dependent field / group. This would also improve performance if we also had a way to set dependent field values and running Kernel computations in one go (which we will maybe get soon).
As Andreas noticed, it would require that you write your rules in a way that does not rely on hidden fields being cleared - but as far as I understand it this is a good idea so thatfull validation works properly (on the server).
At the moment we don’t distinguish between “hidden by business rule” (your case) and “hidden by UI interaction” (e.g. collapsing a section, changing screens). This produces wierd (part) validation results, so changing that would also improve that.
Also, because of the Client and Form Engine separation and their dependencies, “saving” is a concept that only exists in Client. So, from Form Engine side we would provide a function that you would need to call to remove the irrelevant values. And maybe add a flag to our built-in data providers in Client.