Updated: Comment #N
Problem/Motivation
Splitt-off of #2002138: Use an adapter for supporting typed data on ContentEntities.
We want to rename that method on entities to toArray() to have common method to get an array representation of an entity. Config entities already had their getExportProperties() renamed.
Proposed resolution
The issue above renames the method on content entities. To make that issue smaller, because it's going to grow a lot before it's done, let's just rename getPropertyValues() on ComplexDataInterface as well and remove setPropertyValues() there as well. It's never used outside of tests and if we want to, we can just let setValue() take it's place if we want to?
Remaining tasks
User interface changes
API changes
Comment | File | Size | Author |
---|---|---|---|
#27 | entity-toArray-2223361-26-interdiff.txt | 1.54 KB | Berdir |
#27 | entity-toArray-2223361-26.patch | 14.53 KB | Berdir |
#24 | entity-toArray-2223361-24-interdiff.txt | 1.41 KB | Berdir |
#24 | entity-toArray-2223361-24.patch | 13.77 KB | Berdir |
#21 | interdiff.txt | 1.3 KB | tim.plunkett |
Comments
Comment #1
tim.plunkettAwesome
Comment #2
BerdirLet's see how this goes.
I also want to promote usage of $entity->get('some_field')->toArray() over getValue() now that we have this but that can be a follow-up issue and wouldn't be an API change but it would also help to keep the size of #2002138: Use an adapter for supporting typed data on ContentEntities down. I'll open another issue.
Comment #4
BerdirUhm, not sure how that happened.
Comment #6
BerdirOk, doing the lazy thing for now, there are various test entity classes that extend directly from Entity and now need that method, including mocks and so on.
Comment #8
tim.plunkettSee #2223423: Stop extending \Drupal\Core\Entity\Entity in unit tests for the non-lazy solution.
Comment #9
BerdirFixing those test fails, missed that the removed call changed the value.
Comment #10
tim.plunkettWorks for me. @Berdir++
Comment #11
BerdirWould like to have the OK from @fago on this as well, let's give him some time to comment on this.
Comment #13
tim.plunkett9: rename-get-property-values-2223361-9.patch queued for re-testing.
Comment #15
tim.plunkett9: rename-get-property-values-2223361-9.patch queued for re-testing.
Comment #16
catchLooks like retests don't change status. Back to RTBC.
Comment #17
fagoYeah, this works for me. As said in some other issue, I'm +1 on toArray(). I'm not so sure about removing setPropertyValues(), but given it's close to no where used it seems pointless to keep it.
However, as toArray() is now defined in ComplexDataInterface and EntityInterface which the content entity both implements, I think we should make sure the docs align well. Thus, I've worked a bit on the docs, please review the attached changes and updated patch.
Comment #18
fagoFixed a comma which should be a point.
Comment #19
BerdirHm, computed is a concept that doesn't really exist on EntityInterface.
Comment #20
fagoI know it doesn't have computed stuff *formally*, but still I think it makes sense to have it there as many entities have *informally* computed stuff - i.e. an entity could have $entity->data which is somehow computed and customly set. This shouldn't be in there though.
Comment #21
tim.plunkettThat comment seems specific to content entities, why not just add the docs on ContentEntityBase? Since we're not allowed to append docs to {@inheritdoc}, just replicating them.
Also, in case someone disagrees and moves it back, note that I corrected "not-computed" to "non-computed".
Comment #22
BerdirYeah, that makes more sense to me for now as well.
@fago is right that config entities have computed things but those aren't values for me (like the plugin (bag) for those that have that.). Maybe we can describe it in a different way somehow, I think the idea is that you can call toArray() of an entity and pass those values to a new entity object and you then basically have the same entity.
Also, the overlap will be less problematic with the adapter approach as ContenEntityBase will no longer implement both interfaces.
Comment #23
fagook, works for me but shouldn't the clarification be on ContentEntityInterface then? It's not only a matter for the base class implementations.
Comment #24
BerdirOk, like this.... ? please? :)
Note that I also changed property to field as it's now on ContentEntityInterface. I explicitly avoided using property or field in the original patch :)
Comment #26
fagoStill property and fields ;) Except for the fail, this looks good now.
Comment #27
BerdirFixed the new test and comment.
Comment #28
fagoGreat!
Comment #29
alexpottCommitted 2815203 and pushed to 8.x. Thanks!
Comment #31
alexpottWe probably need to check existing change notices too