[2.0.0-alpha3] Field Formatters : views, nesting & context handling

Same MR as 🐛 [2.0.0-alpha2] Formatters: functional feedbacks from alpha1 Needs review

Tested with a node's title field:

• For each: ❌ the form doesn't load
• For all: ✅ We see only field properties now. According to Mikael, it is a generic "universal" system instead of just covering views' context.

For each: ❌ the form doesn't load

-> this is true when the field formatter "for each" is not applicable, when the cardinality of the storage is 1 at most.
if you select a field with cardinality superior or equal to 2, the for each will work in views.

i have checked the code, i am not 100% sure, but the list of formatters which is proposed in the views field option form, do not reflect the result of the method "isApplicable" inside the field formatters.

according to what i have seen the line in class "Drupal\views\Plugin\views\field\EntityField" from views module.
$formatters = $this->formatterPluginManager->getOptions($field->getType());

so what do we do?

A little update with my new batch of tests

• "For all" on a single value field: ✅
• "For all" on a multivalued field: ✅
• "For each" on a single value field: ❌ the form doesn't load
• "For each" on a multivalued field: ✅

Before fixing "For each on a single value field" let's talk about those 2 formatters.

Why do we have field properties source on "for all" ? It make sense when "For all" is applied to a single value field, but what is expected in a multivalued field?

Proposal

"Component (For all)" is renamed 'Component wrapper" (or something like that...) and has those sources:

• Field label
• Field formatter (with the full renderable)

"Component (For each)"is simply renamed 'Component", is available for both single value and multivalued fields, a has those sources:

• Field label
• Field formatter (if the render array is a list, we take the corresponding rendered item; if the render array is a single renderable, what do we do? We return it or we reurn nothing?)
• Field properties...

Both are available for multivalues & single value fields.

About for each and for All,
why not just use the terms "Components"
(for each), and "Component"?

i take this one

Hello,
as we discussed during the camp, i made the changes to allow better field formatter naming and working.
i think this MR is one of the toughest i have made during the last weeks, but it brings so much goodness :

+ better source plugins management for slots and props, through a better handling of contexts. Especially custom contexts which are
specified by ui patterns sources and have constraints (views source plugins, field prop source plugins...etc). The magic really happens now
The modification allowed also to clean the ".module" of ui_patterns_views and put the right code at the right place inside each ui patterns views ' source plugins ;)

+ some bugfixes on ui_patterns_field_formatters, which were appearing during nesting. the nested field formatter was not handling correction the field definition..

+ some renaming of the two field formatters which are "Single component" and "Component per item", to allow better understanding of what's happening when you render a field and its items with ui patterns.

+ renaming of field formatter PHP classes for better homogeneity

please review

Merged

Automatically closed - issue fixed for 2 weeks with no activity.