Hello guys,

I think there is a design limitation for now in the FieldTypeInterface.

Ex:
https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/FieldType/Selection/Type.php#L125
https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/FieldType/Relation/Type.php#L125

The getName method should take in argument or optional argument the FieldDefinition.

Because right now, it seems impossible to correctly define the getName() of a Selection for instance.
But it's bigger than just the definition as the Relation FieldType will need the destination object and then an access to retrieve this object.

I see one way to do that easily and probably in the right way.
Everything ( I need validation here) is done here:
https://github.com/ezsystems/ezpublish-kernel/blob/master/eZ/Publish/Core/Repository/Helper/NameSchemaService.php#L253

Then we could:

• add a new method in the FieldTypeInterface called getSchemaName
• implement this method and rely on getName in the abstract class eZ\Publish\Core\FieldType\FieldType
• inject the Repository in the NameSchemaService

=> the signature of the getSchemaName method would be:
getSchemaName( $value, $fieldDefinition, $repository ).

In this way, there is no need to change anything in the actually classes and we have just to implement the getSchemaName.

The cons is about the getName() but it won't be crazy for me that the getName of a selection return the "id" of the choice(s), and for the Relation the id(s) of the destination...

well there are my thoughts What do you think ?

++