[meta] Implement the new entity field API for all field types

Updated issue summary.

A couple hints on what exactly needs to be done would probably help ;-)

Little help for others:

• See code #1839070: Implement the new entity field API for the taxonomy reference field type as example
• Don't try it on nodes, as it won't work. currently only entity_test extends EntityNG -- so all you testing should be against that entity type.

@fago,
I'm working on adding property info for ER, some questions:

1. Should I move the current EntityReferenceItem under ER module?
2. The current implementation assumes $this->definition['settings']['entity type']; but in ER the value is in $this->definition['settings']['target_type']; -- should I rename the keys?
3. ER comes with revision ID support. If the key is NULL we use entity_load, otherwise, we load by revision. How should I treat 'settings' => array('id source' => 'value'), as the source ID is infact chaned on the fly per delta (i.e. not even on the field level, but on the field values)

> However, what about having a separate type for revision references?

The thing is that the same field on the same entity, can reference one time an entity by ID, and one time reference by revision ID. for example:

field_reference['und'][0] = array('target_id' => 1, 'revision_id' => NULL); // Use entity_load()
field_reference['und'][1] = array('target_id' => 5, 'revision_id' => 10); // Use entity_revision_load()

> Is that valuable to have in the same field?

I guess this is something we need to figure out. The revision ID support doesn't exist yet in D7, so I don't have experience with it. I wonder if we should add a checkbox to the UI, saying "Use revision ID" -- in that case I don't even know how/ if we should show a widget.

I could start with a simpler implementation to deal only with the entity ID, and not with the revision ID, until we figure out how it should work.

Re: 'entity type' :
Please keep in mind that with 'field types as plugins', all of these will be in annotations, so we should settle on underscore separated properties.

Right. Yaml keys in CMI files are another reason, actually.

Also, 'field types as plugins' means field type implementations will consist in providing one 'field type handler' class - which probably won't be the same as the 'field item (aka value)' class mentioned here. That would mean providing two classes for a field type.

Or is there a base 'field item' class that could be the same for most field types, and reference fields being the exception that needs to provide a dedicated item class ?

#1839070: Implement the new entity field API for the taxonomy reference field type now contains a working example of what needs to be done.

Note that this issue currently only covers the first step of this conversion. The whole thing is tracked in #1346214: [meta] Unified Entity Field API but doesn't list this issue yet. Once this is done and all entity types are converted to NG, we can start converting how we access these fields and also convert Field API itself. Then we can finally remove the BC layer :)

I think we'll always need a custom field item class, as that's the one you are implementing for providing the defintition of contained properties/columns.

Well, precisely, providing the definition of contained properties/columns was not something I would have considered for the 'item' class, because you want that list in cases where you don't have an actual field value from an actual entity - like, to create the sql table on creation of the field.
There are also the methods that operate on multiple entities (like 'load', 'prepare_view'), and therefore on multiple items.

Well, I won't be focusing on "field types as plugins" before Dec 1st anyway, we'll have opportunities to discuss this :-)

Updated issue summary.

@fago,
How do I get the field name in getPropertyDefinitions()?
I expected that implementing ContextAwareInterface would be enough, however when I $this->getParent() I don't see the field name.

No, I mean something else-- in EntityReferenceItem::getPropertyDefinitions() we currently have :
$entity_type = $this->definitions['settings']['entity type']

But this is of course not yet populated. The entity-type should be extracted from the field info, so I expected to do something like:

$field = field_info_field($this->getParent());
$target_type = $field['settings']['target_type'];

But even though I changed class EntityReferenceItem to extend ContextAwareInterface $this->getParent() doesn't work.

fago pointed me to this -- http://api.drupal.org/api/drupal/core!modules!field!field.module/functio...

Bumping status.

Updated issue summary.

add telephone issue

An ignorant question:
Does this need to be done for the new Date field type too?

the date field type already provides a DateItem class, the only thing that is missing are are unit tests for it I think like all other field types now have.

The last issue in the OP was committed so I guess we can mark this fixed. Yay!

Yay!