Before #1497374: Switch from Field-based storage to Entity-based storage, configurable $field structures were not tied to a specific entity type, only $instance was.
So, since both $field and $instance implement FieldDefinitionInterface, getEntityType() was left out of it.
But now, a configurable $field *is* tied to an entity type. Base fields are tied to an entity type as well.
So there should be a FieldDefinitionInterface::getEntityType() ?
(note: $field and $instance, by being ConfigEntities, already have an entityType() method, we should disambiguate - so maybe getTargetEntityType() ?)
Comment | File | Size | Author |
---|---|---|---|
#42 | 2134967-42.patch | 4.25 KB | plopesc |
#38 | interdiff.txt | 1.2 KB | plopesc |
#38 | 2134967-38.patch | 4.23 KB | plopesc |
#36 | 2134967-36.patch | 4.2 KB | plopesc |
#21 | interdiff.txt | 911 bytes | swentel |
Comments
Comment #1
fagoYeah, I think that would be consistent on how we treat field names already, i.e. the field definition knows about its context. This is already the case for configurable fields, and I don't see a problem with doing it for non-configurable fields also.
FieldDefinitionInterface::getEntityType() would be nicer, but yeah to disambiguate I'd vote for getTargetEntityType() also.
Comment #2
yched CreditAttribution: yched commentedEasy task
Comment #3
swentel CreditAttribution: swentel commentedComment #5
swentel CreditAttribution: swentel commented3: 2134967-3.patch queued for re-testing.
Comment #6
swentel CreditAttribution: swentel commentedComment #8
swentel CreditAttribution: swentel commented6: 2134967-6.patch queued for re-testing.
Comment #10
yched CreditAttribution: yched commentedYup. Thanks!
Comment #11
chx CreditAttribution: chx commentedWouldn't getParentEntityType be better? Just because typed data uses the parent concept and these are not reaaaaally references. I am not here to bikeshed but this name does not mesh well with either concerns.
Comment #12
fagohm, personally I'd favour the target variant. The entity is not the parent of a field definition, but I could see a field definition targeting a certain entity type (so it references an entity type).
Comment #13
yched CreditAttribution: yched commented+1 on "target" too, for the reason @fago mentioned, + I advocate to keep TypedData API as "in the back" as possible, so I'm not too keen on modelling domain interfaces on it :-)
Temptatively setting back to RTBC ?
Comment #14
webchickHm. The word "Target" means nothing to me, personally. It sounds like something an Entity Reference field would have, but this is just a regular ol' field definition. So colour me confused. :( ("Parent" doesn't really help either, FWIW.)
$field->getEntityType() sounds perfect to me, personally. But it sounds like this was deliberately not chosen because it already exists (from "(note: $field and $instance, by being ConfigEntities, already have an entityType() method, we should disambiguate - so maybe getTargetEntityType() ?)" in the issue summary). But then I do not understand what the difference is between this method and $field->getEntityType().
Could we maybe add some tests to clarify..? Since there's nothing in core using this method it's hard to grok for a newcomer to field/entity API.
Comment #15
yched CreditAttribution: yched commented@webchick:
$body_field->entityType() == 'field_entity' (method from EntityInterface - you're an entity, what's your entity type ?)
$body_field->getTargetEntityType() == 'node' (method from FieldInterface - you're a field, which entity type are you attached to ?)
Comment #16
ar-jan CreditAttribution: ar-jan commentedMaybe getHostEntityType() ?
Comment #17
yched CreditAttribution: yched commentedMore broadly speaking:
- There are a lot of config entities that store something "related to an entity type", possibly related to "a specific bundle in this entity type".
- Those typically have 'entity_type' / 'bundle' properties in their CMI file, resulting in $entity_type / $bundle members in the corresponding ConfigEntity classes.
- We're looking for good accessor method names for those properties, considering that, by virtue of being a ConfigEntity, there already are entityType() / bundle() methods (for "what is *your own* entity type / bundle as an Entity).
Ideally each ConfigEntity that fits that pattern should not have to come up with its own method names. getHostEntityType() might kinda sorta work for fields since you could say that a field "is hosted" by an entity type (even though we currently don't use that specific terminology anywhere in code / comments / UI, so that would still feel weird IMO). But "hosted by" seems totally unfit to qualify the relation between, for example, an EntityDisplay and the entity type/bundle it is associated with.
In that sense, getTargetEntityType() / getTargetBundle() feel more neutral. "Those are the entity type & bundle I, as a piece of configuration, am talking about".
Comment #18
webchickOk, let's keep target (only other word that springs to mind is "attached" but that probably has other connotations in Field API), but update the docs to make it more clear how it's distinguished from getEntityType(). Something along the lines of #15 would work.
Comment #19
swentel CreditAttribution: swentel commentedNeeded major reroll - useless to have an interdiff.
Comment #20
yched CreditAttribution: yched commented#19 works for me.
Suggestion to address @webchick's request in #18:
FieldDefinitionInterface::getTargetEntityType():
?
Comment #21
swentel CreditAttribution: swentel commentedComment #22
chx CreditAttribution: chx commented1. webchick suggested attached 2. the doxygen suggested attached. So then let me suggest getAttachedToEntityType ...
Comment #23
yched CreditAttribution: yched commentedgetAttachedToEntityType() ? hardly seems a win, it's ugly and doesn't mean anything...
Comment #24
amateescu CreditAttribution: amateescu commentedI also don't think getAttachedToEntityType() is an improvement. #21 is RTBC for me, unless @webchick has some input on the text from #20.
Comment #25
plopescRe-rolling #21, as commented with @swentel on IRC.
Comment #26
yched CreditAttribution: yched commentedThis looks wrong ? $base_definition is a FieldDefinition object, not an array ?
Oops.
Comment #27
plopescAddressing comments in #26
Comment #28
XanoIs this the best way to fix this? $base_definition is a FieldDefinitionInterface, not an instance of a particular class.
Comment #29
yched CreditAttribution: yched commentedThere are currently no setters on FieldDefinitionInterface, because FeidlDefinitioninterface is too generic (used for base fields, configurable fields, configurable field instances, and there are no setters that make sense for all of those). Separate mess.
baseFieldDefinitions() really returns an array of FieldDefinition objects, not FieldDefinitionInterface...
This being said - FieldDefinition::getTargetEntityType() returns $this->definition['entity_type'], so it doesn't look like $base_definition->entity_type = $entity_type will work.
The previous patch ($base_definition['entity_type'] = $entity_type) did work because FieldDefinition / DataDefinition has an ArrayAccess layer that writes to the protected $this->definition :-/
I'd say we need a setTargetEntityType() method on FieldDefinition...
Comment #30
plopescAdding method
setTargetEntityType()
toFieldDefinition
. Also adding NULL fallback forFieldDefinition::getTargetEntityType()
.I considered adding
setTargetEntityType()
toField
andFieldInstance
classes and moving it toFieldDefinitionInterface
, but I think this i not useful because$entity_type
is set in the constructor of these classes and I did not found any place in core where this value is modified.Any thoughts?
Regards.
Comment #32
plopesc30: 2134967-30.patch queued for re-testing.
Comment #33
yched CreditAttribution: yched commentedLooks good to me. Thanks !
Comment #34
yched CreditAttribution: yched commentedSigh; I suppose this should be getEntityTypeId() now...
Comment #35
BerdirYes, it should.
Comment #36
plopescRenaming methods to
getTargetEntityTypeId()
andsetTargetEntityTypeId()
Comment #37
BerdirThanks, can we make the method description abit more explicit and say that we're returning the ID of the entity type? See changes in #2180725: EntityInterface's return values are not or incorrectly documented for a similar improvement.
Comment #38
plopescChanging docblocks.
Comment #40
plopesc38: 2134967-38.patch queued for re-testing.
Comment #41
BerdirThanks!
Comment #42
plopescRe-rolling after #2165155: Change $entity_type to $entity_type_id and $entity_info to $entity_type/$entity_types
Comment #43
catchCommitted/pushed to 8.x, thanks!