Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Belongs to #1346214: [meta] Unified Entity Field API, architectural discussions should happen there.
- Add the defined interfaces (already in entity-property-fago)
- Start to implement this for the TestEntity (working on this, will be in entity-property-berdir soon)
Comment | File | Size | Author |
---|---|---|---|
#4 | property-uml.jpg | 75.97 KB | Berdir |
#3 | entity_property-1637642-3.patch | 1.55 KB | tim.plunkett |
Comments
Comment #1
BerdirOk, commited an initial, largely hardcoded version of the entity property API.
The following part of the tests already work:
Saving doesn't work yet, because the properties are protected and then drupal_write_record() recieves EntityProperty objects and freaks out. But we will need to stop using that function anyway for the upcoming _property_data tables anyway.
Comment #2
fmizzell CreditAttribution: fmizzell commentedDo we really have to do that? can we get rid of "entity": $entity->user->name
Comment #3
tim.plunkettAFAIK, a class may not implement two interfaces with the same method names.
And PropertyContainerInterface duplicates a half dozen method names, conflicting with EntityInterface and PropertyListInterface.
Comment #4
BerdirAs I understand we don't want to get rid of entity however, for these cases, the idea is that the object will provide convenience methods, so that you can do:
$entity->user()->name->value, or $node->author()->label().
Having the same method in multiple interfaces is fine as long as they don't conflict.
Having these e.g. is fine:
This wouldn't work:
The get/set methods from EntityInterface have an additional langcode, in other cases there is (or will be) additional documentation. And the validate()/access() methods are in parallel interfaces, which are, in the case of entity properties combined, but that's not required so that's why they are in both.
See the attached image, which contains a simple and incomplete class diagramm of all these classes.
Comment #5
tim.plunkettDid you try using your branch? It fatal errored for every conflicting method. None of them have different signatures, so they're not overloaded or anything.
Comment #6
BerdirYes, as I said, the tests were passing for me. A least the ReadWrite tests.
Comment #7
Crell CreditAttribution: Crell commentedI still firmly believe that entity() should be a method of a reference property, not an extra-magic pseudo-object-property. It's way more clear what you're doing there, and easier to standardize, and doesn't create a magic constant value.
Comment #8
miro_dietikerReferring to my document that tries to cover the topic on how to build a perfect multilingual / revisionnable system that allows to finally make content translation unneeded without regressions for typical advanced usecases.
http://techblog.md-systems.ch/blog/2012-06-drupal-8-multilingual-and-rev...
Feedback as comments there appreciated. (signup required..)
Comment #9
fagoI've done more work on that recently, check the entity-property branch. It's basically working, but still lots of stuff is open and todo. Let's figure the details out in specific issues -> I've create a bunch of those, please just add yours as well.
Comment #10
fagoAs said, let's figure the details out in specific issues. For status-updates and the like, I'd suggest to use the core-issue #1696640: Implement API to unify entity properties and fields which we then can use for posting the initial patch as well.
Given that, this issue is useless, so let's close. Please follow the core-issue instead and/or post to specific sandbox issues. Thanks!