Layout & Expression changes due to supporting multiple data models

[bjosttveit]

Description

Supporting multiple data models in app frontend should mostly work with app-lib-dotnet out-of-the-box, as it will fetch and update each data model independently.

Where things could (and probably will) go wrong is where app-lib does its own layout parsing and expression evaluation. The relevant changes are that dataModelBindings now optionally can be defined using an object specifying both the path, and the dataType, like this:

"dataModelBindings": {
  "simpleBinding": {
    "property": "some.field",
    "dataType": "dataModelName"
  }
}

Additionally, to support multiple data models in dataModel expressions, a third optional parameter has been added, making the following valid:

["dataModel", "some.field", "dataModelName"]

component expressions will also be able to reference any data model through its dataModelBindings, but the configuration there has not changed.

Meaning that in order to support this, it is no longer enough to have the "default" data model (defined in layout-sets) available, as the layout and expressions can reference any data model defined in the app.

The ExpressionValidator kind of already supports this, insofar as they are already defined on a per-data-model basis. However, it currently still needs to be able to ignore hidden data, and therefore still relies on being able to parse the layout and run all expressions.

There are no breaking changes in the config, meaning that existing apps should work in the same way as before. However, when actually trying to use and reference multiple data models I suspect that this will cause the app backend to crash when it tries to parse the layout and run expressions.

App-Frontend issue #1709 again comes to mind, as offloading the work of removing hidden data, and updating the backend validators accordingly would go a long way to resolving these issues. We could even say that referencing other data models in expression validation is not allowed, meaning we would not need to fetch potentially all data models when validating a single data model with expression validation.

The other option is of course updating the logic in app-lib to support the extended dataModelBindings functionality, and making several / all data models available when running expressions there.

In scope

• Reference current sub-form/datatype ie. expressions that points to components within the same layout.
• Reference other datatype that has 1 as it's maxCount

Out of scope

• Reference sub-forms (underskjema) ie. datatypes with more than 1 as maxCount.

Additional Information

• This should be implemented as a opt-in solution leaving existing implementations working as-is.
• This will today be triggered by enabling one of the following (which are false by default):
  • Required
  • ExpressionValidation
  • RemoveHiddenData

The code where "things happen" are:
* LayoutEvaluator
* RequiredLayoutValidator
* ExpressionValidator
* ProcessTaskFinalizer

Analysis

No response

Conclusion

No response