Page History

Related issue 

Goal

We want to provide users with a simple, modern API to build arbitrarily complex fields.

Problem

All is good, as long as a simple value is bound to a simple field, e.g. TextField → String. 

But what if I need a field manage a complex nested value, i.e. if I have to manage hierarchical data?

Currently Magnolia does provide such ability through custom multi fields (see AbstractCustomMultiField) but they have several shortcomings, both in terms of internal implementation and from a client developer's perspective (see for instance 

...

• Assume the field is simple and atomic

• When you need to manage many related values - it is another form within a form

• Complex fields are like forms but with striped layout.

Layouting 

Form (or editor) layout should be separated from the binding mechanism and should be flexible

• first we produce the field/sub-form components and bind them to the binder

• then we pass the mapping of e.g. the property names and the resulting components (fields/sub-forms) to a layout producer

• the layout producer could yield a tabbed layout that we have currently or any other type of layout based on the configured definition

A class diagram from the current PoC and a description of their main responsibilities

...