OEL-3000: Add (Sub)SectionPattern field group formatter.

[donquixote]

Changes:

• New base classes for field group formatters.
• New field group formatter SectionPattern.
• New field group formatter SubSectionPattern.
• New kernel test as alternative for the functional test. (It is faster!)

Up for discussion:

• Old vs new base classes. The new base class has some benefits (imo) but it can create confusion to have multiple options. I think we don't want to remove the old base class, it will create BC issues.
• Do we need the pattern variant option for 'section' pattern? It is only relevant if a sub-theme introduces variants for this pattern.
• Do we want two separate formatters or a single formatter with config? I prefer separate, to make it easier to apply them en masse without going into the settings sub-form. We could use a plugin deriver, but for now I just propose two separate classes.
• Do we need more levels like sub-sub-section?
• Do we want to use this field group formatter for existing cts?
• Should we test this in combination with in-page nav?
• Is .mb-5 a good choice for the section margin? In our project we use .my-5, but we have a trick to clear the top margin (the .eat-margin-top trick).

[donquixote]

I am not sure I understand the needs for the "better detection of empty elements".

For this you can check my other comment..

I do not agree on having a dedicated formatter per variation of classes, with tiny differences like attributes/tags.

The alternatives would be:

• The ui_patterns_field_group module (see below).
• A single field group formatter class with a plugin deriver. This makes sense if we have a range of variations, e.g. h2, h3, h4..
• A single field group formatter class with a config option to choose the heading level (which should also set the spacing).
• (In a possible future, similar to what we did in SRB, we would have had a pattern contract for a "content + label" pattern, and the "section" pattern would implement that contract.)

The motivation here was to be able to quickly configure content type displays with many different sections, where a "section pattern" is the natural default formatter. The most common behavior should be achievable without going into the options subform.

The ui_patterns_field_group is the opposite of this, and requires lots of maintenance to achieve the basic behavior. The need for an extra field for the title..

What I did in the branch POC/OEL-3000 is:

• install ui_patterns_field_group module.
• created an extra field that renders a label only if the section fields are not empty.

We need to avoid that individual websites need to create extra fields where they have to hard-code the field names. And I think your emptiness check in the extra field is not even fully reliable, because it does not cover the case where a field has content, but the visitor has no access to it.

• created a field group using the pattern formatter. Moved the fields above like in this picture: [...] With this little piece of code and the configuration in the page, the section was rendered only when the inner fields were not empty.

But this "little piece of code" would have to be replicated across different website projects, for different field groups.

And if you add a new field into the group, now you need to update the field mapping in the group settings, and you need to add the new field in the condition of the extra field.

The classes can be customised per field group instance.

We should avoid having people customize classes for each field group, if the main use case is to have standardized section and heading levels with standardized spacing.

The goal of the new patterns that we will be implementing will be to move as much towards this approach.

I think the pattern integration modules shipped with ui_patterns are a dead end, because they have to accommodate a wide range of possible pattern parameter signatures. This always deletes to complex configuration forms, with many degrees of freedom, and no validation to determine if a field mapping makes sense with the parameter type.

---

The goal should be to reduce complexity and unnecessary choice in the website projects,