Posted by fago on November 18, 2011 at 6:07pm
84 followers
Jump to:
| Project: | Drupal core |
| Version: | 8.x-dev |
| Component: | entity system |
| Category: | feature request |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | active |
| Issue tags: | Configuration system, D8MI-meta, DX (Developer Experience), Entity system, Favorite-of-Dries |
Issue Summary
This is a meta issue for completing and improving the entity API for Drupal 8.
Goals
- Complete the API (i.e. implement full CRUD)
- Improve DX (classed objects, ..)
- Full support for diverse storage engines, remote storage per entity-type.
..?
Roadmap
Step 1: The base: CRUD, classed objects based upon a defined interface
- #1184944: Make entities classed objects, introduce CRUD support
- #1277776: Add generic field/property getters/setters (with optional language support) for entities
- #1233394: Agree on a property naming pattern
- #1346032: Ordering of hook_entity_delete() is inconsistent
- #1301106: Rely on methods to access entity properties [policy, no patch]
Step 2: Convert all entity types to classed objects:
- #1361226: Make the file entity a classed object
- #1361234: Make the node entity a classed object
- #1361232: Make the taxonomy entities classed objects
- #1361228: Make the user entity a classed object
- #1615236: Merge entity controller interfaces, document and add default entity class definition
Once the above issues are complete:
- #1618172: Remove entity_uri() in favor of EntityInterface::uri()
- #1615240: Remove entity_label() in favor of EntityInterface::label()
Rely on. Not possible, see [#1551140].entity_create()in entity_create_stub_entity()
Step 3: Multiple controllers/decoupling: Lay the foundation for adding more entity-based functionality.
- #1302378: Use multiple specialized entity controllers
- #1596472: Replace hard coded static cache of entities with cache backends
- #1612014: Create an interface for revisionable entities
Step 4: Add further APIs around entities
- #1346214: [meta] Unified Entity Field API
- Entity Validation (based upon property level validation API)
- Entity Access API (+ property level access). #777578: Expand the node access API to a general entity access API to improve security
- Entity Form system. #1499596: Introduce a basic entity form controller
- #1026616: Implement an entity render controller
Misc, but major issues without any particular order:
- Implement full revision support in the database storage controller
- #1374116: Move bundle CRUD API out of Field API
- #1391694: Use type-hinting for entity-parameters
- When revisions are done ==> #1374030: Remove entity_extract_ids() now that we have proper classed entity objects
- Refactor EFQ to build upon the storage controller
- Unify the storage system (Field storage + entity storage):
- Discussion: #1497374: Switch from Field-based storage to Entity-based storage
- Related sandbox: http://drupal.org/sandbox/damz/1496468
- #1810370: Entity Translation API improvements
General sandbox:
http://drupal.org/sandbox/fago/1497344
Let’s use this issue for high-level architecture discussion and update the roadmap accordingly.
Thoughts?
Comments
#1
Looks superb. Tagging DX and D8MI.
#2
Also tagging cmi. Looks great.
#3
Another thing we will want to look at is how we're going to introduce UUIDs into entities. I will probably make a new issue for that as well. I think it makes sense for this to happen after all the entities are converted maybe?
#4
From #1184944-151: Make entities classed objects, introduce CRUD support:
I don't see revision support explicitly listed above. I'm assuming it would be an additional item in step 1, before we start on the other entities?
#5
You're right, though, we need that to convert nodes.
#6
when re-factoring revisions take a look at #218755: Support revisions in different states
It's not much different from #1082292: Clean up/refactor revisions
#7
Alright, I moved the note about revision support up to Step 1.
#8
We don't necessarily need proper revision support for being able to port nodes over, as we can just move the revision specific stuff into the controller. That way, we could focus on porting everything over first and then get revisions right.
#9
I've added follow-up issues to the summary and moved the revision-controller to the major issues without particular order.
#10
Cross-referencing:
#11
I'd love to see those follow-up issues classified as major "feature requests" rather than tasks. It's not really very equitable to the rest of the team for a single initiative to block progress on all other initiatives by pushing us up over thresholds by splitting up the work into sub-issues.
Totally cool with this issue remaining a major task, though.
#12
Ah, yes, +1 for switching them to feature requests. They are kind of bullying major tasks at the moment. :) I've switched them to feature requests for now, unless someone disagrees?
#13
I'm fine with downgrading the individual issues from major task, but think we should open a single critical issue (not this one which is about further API additions/changes) to track them.
Converting existing entities to the new API is essential to uncover issues with what we just committed (as we found out at length with field API), and needs to happen earlier rather than later in the cycle (and it's critical to update all core entities before we get to release, so critical feels about right for that).
#14
Well, if we want to make real use of the OO API (introducing language consistently as well as adding UUID support), we should do the conversion sooner than later. So I hope it is not just done later up to the release :) Or if the OO conversion is to be delayed, we should add UUID and language with the old methods and the conversion will be just more work that way. Not sure its better in that direction.
#15
Yeah I couldn't agree more, opened #1368394: Convert all core entities to classed objects.
#16
I added #1374030: Remove entity_extract_ids() now that we have proper classed entity objects to the todo list
#17
#18
Added #1374116: Move bundle CRUD API out of Field API
#19
Added #1391694: Use type-hinting for entity-parameters
#20
It would be very nice if we could actually keep entity_label() around. It works very well as a title callback for menu router items.
#21
Actually, I would like to keep entity_uri as well for similar reasons.
#22
I've added #1301106: Rely on methods to access entity properties [policy, no patch] to the summary.
Indeed, that could be used for term and node view pages. However, I'd still prefer renaming it to make clear people should use
$entity->label()now. E.g. we could have entity_page_title() analogously to node_page_title(), which just calls$entity->label().@entity-uri: I'm not aware of any use-case for that, but if there is one I'd suggest doing the same as for the label. Add a function that's clear purpose is being a callback.
#23
That's recursive ;) Not that I can talk, I've marked dozens of issues duplicate of themselves...
#24
Well, GNU is my inspiration :D Fixed it.
#25
Move to new D8MI-meta tag.
#26
Tagging.
#28
Also see the related discussion over at #1497374: Switch from Field-based storage to Entity-based storage
I'ved added a pointer to that issue + the according sandbox to the summary.
#29
Couple followups from the user conversion:
#1537434: Add type-hinting to user entities
#1537442: Rename $user->access and $user->login
Edit: I didn't know where to put these on the roadmap in the summary. :)
#30
Do we have to make an issue to convert
"field_test_create_stub_entity"
At the moment it returns a stdObject but this is incorrect. It should return a proper entity.
That also blocks some followups like remove entity_label().
Problem: it sometimes adds a version ID which is only possible for nodes.
#31
First stab to the Entity form system in #1499596: Introduce a basic entity form controller. Early reviews welcome :)
#32
Opened #1615236: Merge entity controller interfaces, document and add default entity class definition and added it to step #2.
#33