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

Gábor Hojtsy’s picture

This 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.

fago’s picture

Matter of fact is that config sequences (which seem like lists :) can contain items of various types.

I 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.

fago’s picture

Matter of fact is that config sequences (which seem like lists :) can contain items of various types.

oh, 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.

fago’s picture

Component: base system » typed data system
Issue tags: +typed data
fago’s picture

Issue tags: +Entity Field API

This idea was generally well-received during drupalcon discussions and the core conversation, so let's do it.

fago’s picture

Issue tags: +Typed sanity

tagging

dixon_’s picture

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.

fago’s picture

fago’s picture

Issue summary: View changes

fixed missing '

fago’s picture

Issue summary: View changes
Status: Active » Fixed

Status: Fixed » Closed (fixed)

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