Currently lists are defined like that:
$definition = array(
'type' => 'item_type',
'constraints' => array('item constraints'),
'list' => TRUE,
);
That's a bit confusing as it's not very clear that all keys correspond to the items contained in the list. So feedback has been that a type 'list' would make more sense. Thus, I'd suggest we change list definitions to work that way:
$definition = array(
'type' => 'list',
'settings' => array(
'item' => array(
'type' => 'item_type',
'constraints' => 'item constraints',
),
),
// And if you want you can have that:
'constraints' => array('list constraints'),
);
Note that via the use of the documented 'settings' key we do not have to invent a new definition-key for specifying the list item details - settings is already the place for type-specific settings. Also, it makes the list type not special at all, any contrib could define it's own custom list type if wanted. That way we can remove the current special 'list class' property, and instead of that simply do:
$definition = array(
'type' => 'custom_list',
'settings' => array(
'item' => array(
'type' => 'item_type',
'constraints' => 'item constraints',
),
),
);
This would also influence how entity fields are defined, as all of those are lists of field items. So to make their definition inline with the above suggestion we could have that:
$definition = array(
'label' => t('A text field'),
'type' => 'field_item_list',
'settings' => array(
'item' => array(
'type' => 'text_item',
'constraints' => 'item constraints',
),
),
);
Whereas type 'field_item_list' points to our current "Field" class.
Comments
Comment #1
Gábor HojtsyThis is very relevant for the config system. Arrived here from #1928868: Typed config incorrectly implements Typed Data interfaces. Matter of fact is that config sequences (which seem like lists :) can contain items of various types. At least it depends on how you define a type. The types of values in a sequence can contain dynamic pieces defined via the items. Such as image styles have a list of effects applied, however effects have unique data structures, so the item type depends on the effect defined. This is documented at http://drupal.org/node/1905070#dynamic-types
So not sure how this would apply to the existing list (sequence) type in config schema.
Comment #2
fagoI know. That's also the case for a list of nodes (or more general entities). E.g. if the list of nodes contains a page and an article node, we would have types like entity:node:article and entity:node:page in the same list. (at least once #1868004: Improve the TypedData API usage of EntityNG has been fixed). That's totally fine, but what you specify as item definition of the list must match to all items, i.e. you cannot specify the types entity:node:article or entity:node:page - but you can specify entity:node - the type who is common to all list items.
Thus, in case of the configuration schema the common parent type could be e.g. "image_effect", "mapping" or - if list items are totally different even 'any' as introduced by #1913328: Provide general list and map classes.
References like
views.display.[%parent.display_plugin]
do not tie into list, thus I'm commenting on that at #1928868-5: Typed config incorrectly implements Typed Data interfaces.Comment #3
fagooh, I did forget to mention the probably most important point here: This would not change the typed-data behaviour in that regard at all - it's already that way as I described #2.
Comment #4
fagoComment #5
fagoThis idea was generally well-received during drupalcon discussions and the core conversation, so let's do it.
Comment #6
fagotagging
Comment #7
dixon_I might take a stab at this before doing #1928868: Typed config incorrectly implements Typed Data interfaces that I need for #2002138: Use an adapter for supporting typed data on ContentEntities.
Not assigning to myself yet. It might take a couple of days until I find time to put aside for this.
Comment #8
fagosee #2047229: Make use of classes for entity field and data definitions, which is about to take care of that.
Comment #8.0
fagofixed missing '
Comment #9
fagoThat got fixed as part of #2047229: Make use of classes for entity field and data definitions.