Updated: Comment #N
Problem/Motivation
MapItem::propertyDefinitions() currently claims that it has a single property named value. That doesn't sense, it can have any number of properties and value is very likely not one of them.
This came up in #597236: Add entity caching to core, which tries to use toArray() to get the values, which doesn't return anything useful for MapItem's right now.
Proposed resolution
The new method doesn't support to define this dynamically, so when called statically, we should return an empty list.
However, we can override getPropertyDefinitions() and when called dynamically, return the actual properties that we have right now, with type any, as we used to.
Remaining tasks
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
#13 | 2229181-13.patch | 1.2 KB | pwolanin |
#13 | increment.txt | 834 bytes | pwolanin |
#11 | d8_mapitem.interdiff.txt | 425 bytes | fago |
#11 | d8_mapitem.interdiff.patch | 1.35 KB | fago |
#9 | 2229181-9.patch | 1.35 KB | pwolanin |
Comments
Comment #1
BerdirComment #2
Wim LeersComment #3
BerdirSomething like this.
Comment #4
fagoI'm not sure we should have that auto-generated values even? Once we'd have some static definitions they would be overwritten by what ever you set on the map, what seems wrong.
We could support defining some metadata for contained properties in the field settings + return them in static propertyDefinitions(). That would allow per instance definitions of contained properties while properly returning that from the field definition also.
Comment #5
BerdirGood point but that does mean that we need to toArray() override from the other issue.
Comment #6
pwolanin CreditAttribution: pwolanin commentedI just got a form error due to cross- post. I was about to say it seems to prevent getting a stray "value" element serialized into the database when using this field type in a new content entity, so that's good, but an alternative to using the any type is to override toArray().
Obviously, you agree. This new patch looks good and also resolves the problem I see.
Comment #7
pwolanin CreditAttribution: pwolanin commentedTo clarify my comment, the kind of thing I was seeing without this patch when creating a content entity with a MapItem field was:
where the 'value' key should not be present.
Comment #8
pwolanin CreditAttribution: pwolanin commentedoops, actually the code comments need some grammer and punctuations fixes.
Comment #9
pwolanin CreditAttribution: pwolanin commentedI think this text is clearer.
Comment #10
larowlansimple docs fix
Comment #11
fagoChanges look good, removed a superfluous empty line though.
Comment #12
pwolanin CreditAttribution: pwolanin commentedthanks - just a blank line back to rtbc
Comment #13
pwolanin CreditAttribution: pwolanin commentedper discussion with alexpott & berdir in IRC, just go back to the simple version since property_definitions is not used in core and should be documented and tested in a follow-up.
Comment #14
BerdirYeah, agreed, we shouldn't introduce a badly documented and untested feature because in case someone will actually need it, it would be broken somehow anyway ;)
Comment #15
pwolanin CreditAttribution: pwolanin commentedFollow-up issue: #2267733: Support field-specific property definitions for MapItem
Comment #16
alexpottCommitted 78594ab and pushed to 8.x. Thanks!
Comment #19
tstoecklerThis introduced a bug and should be rolled back: see #2887105: MapItem violates FieldItemInterface::schema()'s contract - breaks widgets.