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.
Comment | File | Size | Author |
---|---|---|---|
#53 | entity-render-controller-1026616-53.patch | 55.97 KB | Berdir |
#53 | entity-render-controller-1026616-53-interdiff.txt | 2.2 KB | Berdir |
#50 | entity-render-controller-1026616-50.patch | 57.99 KB | Berdir |
#50 | entity-render-controller-1026616-50-interdiff.txt | 9.56 KB | Berdir |
#49 | entity-render-controller-1026616-49.patch | 53.53 KB | Berdir |
Comments
Comment #1
Dave Reidtagging
Comment #2
catchYes please, I would love to get #1018602: Move entity system to a module in first though.
Comment #3
Dave Reidadding tag
Comment #4
fago+1
I've already implemented that by providing a generic implementation in the entity API module. For that it provides a generic "entity" template and a preprocessor, which modules can build upon.
Comment #5
sunStandardizing on "entity" tag, which will be renamed to "Entity system".
Comment #6
moshe weitzman CreditAttribution: moshe weitzman commentedI think we mean that view() should be a method on entity controller. Retitling.
I did work get user_view() to drop all its category nonsense. Hopefully not every entity type will have to override this method.
Comment #7
fagoPlease, let's don't put everything in a single, fat controller. That wouldn't help us.
Let's split up separate tasks (viewing vs. storage?) into separated controllers, ala #1302378: Use multiple specialized entity controllers.
Comment #8
fagoRe-titling.
Comment #9
Dave ReidComment #10
fagoLet's get started with this! :-)
Comment #11
fgmI'm working on this, so assigning for now.
Comment #12
BerdirFYI: The issue that standardizes taxonomy term viewing is #1067120: Missing hook_taxonomy_term_view() or hook_entity_view() when viewing a term.
Comment #13
fgmFirst very raw version:
Not tested, this is just to show where we're going: view() looks fine, next steps are:
Patch applies on top of the one in #1067120: Missing hook_taxonomy_term_view() or hook_entity_view() when viewing a term.
Comment #14
BerdirPatch has a lot of tabs in it, should be easy to fix that.
You should also add the @file docblocks, you can copy them from elsewhere, they're standardized for PSR-0 files.
Obviously lots of documentation still missing, but not that relevant right now.
Will do a detailed review later...
Comment #15
fgmStarted unification of the buildContent() methods.
Comment #16
BerdirNote that all these patches *will* be tested once the issue is set to needs review for the first time, so use do-not-test.patch as the suffix if you don't want that.
Comment #17
fgmRerolled on current HEAD with unification of the buildContent() methods.
Sorry about the tabs. Looks like my IDE reinstall lost some settings.
Next step: actually using these methods to replace the current procedures.
Comment #18
fgmFirst testable version. Works manually, but how many tests does it break ?
Still rolled on top of #1067120: Missing hook_taxonomy_term_view() or hook_entity_view() when viewing a term.
Comment #20
fgmHmmm bot can not apply... maybe with the two patches at once ?
Comment #22
fgmMerging the two patches just for testing. Do not use that patch as such, since it includes #1067120: Missing hook_taxonomy_term_view() or hook_entity_view() when viewing a term
Comment #23
fgmNote that entity_view()-ing vocabularies or files will not cause any error and will return a proper render array, but might possibly something we could want to improve:
Comment #24
fagoMinor, but this could be just one line.
Ouch. I'd really prefer to don't have that complex concept of dependencies and normalizeArguments(). Can we do away with it somehow? Let's discuss.
I think usually we only do that in one line. Also, if no controller is specified the function should default to return FALSE and be documented that way. Maybe, we also want to call it entity_render_controller() and call ->view() on it? So rendering could involved just buildContent() or view().
Override?
Should have comments that it implements the interface.
I think building can be simpler. Just have a look at the entity api module implementation. Add an optional $content parameter being passed in and defaulting to an empty array. Then you can easily override and pass in additional stuff to the parent.
Viewing should be implemented as multiple operation, as this is more efficient. Best have a look at the view() implement of the d7 entity api module.
However, I think entity_view() should be singular, while entity_view_multiple() is multiple.
Also, The docs are insufficient - we need to properly describe all parameters and when the exception is thrown and what gets returned. Same for buildContent().
Misses trailing point.
Makes sense.
Viewing is not a CRUD hook. Thus I guess we should do an entity-view test case that also makes sure the hooks are run.
Why is the single one called show() and not just _view()?
Should be @todo and not exceeed 80chars. Also I don't think we need the question mark ;)
Comment #25
BerdirThe default render widget for a file should display the file, an upload widget would be the edit form :)
I think it's fine to ignore that for now, there's no path to view them, so it can't be invoked outside of code. You might want to talk with @davereid about file stuff, there is an RTBC issue to move the file entity into file.module and the media initiative plans to bring as much of the file_entity contrib module into core as possible, including separate edit and view pages for each file.
Comment #26
BerdirCross-post.
Comment #27
fgmAddressed most of the "simple" issues: remaining ones are:
In detail:
Regarding the CRUD test: there is already a view test, although it would probaby be better simplified, as it currently build the full term page instead of just caring for the entity view, but that is part of the other issue.
I kept the three-line ternary for readability: on one line, the line is too long, and on two lines it is not visually consistent. But of course that can be changed if it matters.
Comment #29
fgmTo be addressed today: view_multiple.
Comment #30
fgmOK, ::viewMultiple() is now implemented and ::buildContent() is now a "multiple" method. Test pass locally for entity, comment, node, term, and user. Crossing fingers.
Comment #32
fgmAhaaa... new kinds of errors ! Fixed the image test.
I'm not sure yet about what's happening with multilingual entities: they appear not to be indexed at all, causing them not to be present in the
node_search_execute()
results, and I have to leave for Paris. Hopefully this version will only fail on those 2 assertions.Comment #33
fgmOooppsie, wrong patch. Same remarks.
Comment #35
fgmNeeds rerolling now that the final version of #1067120: Missing hook_taxonomy_term_view() or hook_entity_view() when viewing a term got in.
Removing the "sprint" tag since the sprint is over.
Comment #36
tim.plunkettI think #1783964: Allow entity types to provide menu items might be an interesting premise for the render controller.
Comment #37
larowlantagging
adding platform initiative because this is needed for #731724: Convert comment settings into a field to make them work with CMI and non-node entities
Comment #38
BerdirHere's a first re-roll.
Lot's to do, just want to see where we're at with the tests and I don't have time to continue right now.
Comment #40
BerdirRe-roll to fix the php errors.
Comment #42
BerdirWorking on this
Comment #43
BerdirOk, here we go.
Spent a lot of time cleaning up, documenting and refactoring this issue.
- Re-added entity_view() and entity_view_multiple(), my previous re-rolls lost them and then stuff obviously broke.
- Unified all view and view_multiple functions to use the same arguments and use the mentioned functions above.
- Removed all remaining build_content functions.
- Documented all render classes according to the guidelines.
- Renamed some functions and changed them to make more sense. The naming didn't make much sense previously, I assume due to refactorings. For example, there was a prepareBuild() method which was called after buildContent(). Changed that to afterBuild() and made &$build by reference.
- Also renamed prepareView() to buildFieldContent(), which is what the documentation says, integrated entity_prepare_view() into it and called it from the default buildContent() implementation. Not quite happy yet with the naming there and the logic.
Let's see what the testbot has to say about it.
Comment #45
BerdirRe-roll, listing patch conflicted with this.
Comment #46
yched CreditAttribution: yched commentedCannot do an in-depth review, unfortunately, here's what I found :
I'm not sure I get the need for buildFieldContent() separated from buildContent() - esp. given that in the current patch buildFieldContent() invokes hook_entity_prepare_view().
(FWIIW, I'm not really convinced by the naming and flow around buildContent() either, but I don't have actual proposals right now :-/. I wish we could get rid of that "build" terminilogy, that is a leftover from #658364: Does build/view/formatter terminology make sense? where we settled on 'view' against 'build' see #9 over there)
Also, the original entity_prepare_view() function had :
"By convention, entity_prepare_view() is called after field_attach_prepare_view() to allow entity level hooks to act on content loaded by field API."
The patch changes that order ?
Not necessarily for this patch, but I think we should remove $node from the signature of comment_view(), and have the $node fetched from $comment->nid in CommentRenderController::buildContent() (there's already code for that in there, btw)
Wrong copy/paste - refers to 'comment' while we're in the base controller.
Comment #47
BerdirThanks for the review!
Agreed, it probably makes sense to merge the build functions together, I'm also happy to rename to whatever is preferred, not exactly sure what yet. Also not sure if we still need to "don't execute this twice" logic anymore in there, because it now always goes through viewMultiple and the function is only called once for all entities. Not sure what should happen if you call entity_view() twice on the same entity, maybe with a different view mode?
I probably messed up the other while merging functions together. Will fix that.
Comment #49
BerdirNice, two fails only and I already fixed these while waiting for the test result :p Tests failed because the old build order didn't match the new one. Not sure if we really want to keep it or fix the tests.
Reverted the order. Sounds like additional test coverage there wouldn't be a bad idea as there weren't
Comment #50
BerdirRe-roll, removed $node from the comment_view() parameters and cleaned up comment rendering a bit.
Comment #51
moshe weitzman CreditAttribution: moshe weitzman commentedCode looks fine, but I am hoping that each entity does not need to override the default. Would be nice to not duplicate similar render code for each entity.
Comment #52
BerdirHm. I'm not sure if we should try to consolidate a lot more. Could make the patch considerably bigger and harder to re-roll. The form controller for example went in with minimal consolidation too and lots of follow-up issues.
I'm quite sure that most core entities will need their own render controllers for a while. Maybe we can somehow unify/standardize link handling (that makes up quite a big part of the custom rendering), there are issues open for that but the logic for comments is quite complex, with threading and stuff. Also, we can possibly build ->content using properties, once all entities have them. But that will take a while.
This default build variables should be relatively easy to get rid of, but might mean quite a bit of code changes, to rename all references to templates and #account/#term. I'm not sure if we should do this in this issue.
To be taken care of in the next re-roll:
oh, tab. Where does that come from?!
Left over that can be removed.
Comment #53
BerdirSetting to needs work wasn't the plan, but it needed a re-roll anyway. Removed some unecessary code while I was it and fixed the tab.
Comment #54
Anonymous (not verified) CreditAttribution: Anonymous commentedI would be really nice if render controllers could be registered on a per content type basis. Something like:
Then serialization modules could simply register their RenderController using hook_entity_info_alter(). This would mean that we wouldn't have to duplicate controller logic within each serialization format module. It would allow the serialization module to focus on what it is there to do—convert the given entity from the data structure we use internally to a serialized representation of it.
Unfortunately, the code that calls the RenderControllers (e.g. node_page_view) assume that the return is a render array, so it would take a lot of refactoring to do such a thing.
Comment #55
fgm@linclark that could be an interesting idea, but better suited to a followup with its own discussion than to this specific issue, which has already been pending for too long, I think.
Comment #56
Anonymous (not verified) CreditAttribution: Anonymous commented@fgm, I agree, I have posted a discussion about it to the WSCCI group. I believe I've figured out a way we could do it without refactoring the page callbacks so it shouldn't be too large of a change, but it can happen in a followup.
Comment #57
BerdirYes, same thought, sounds interesting but follow-up material :)
And as you said in the comment, terminology with controllers is tricky, we need to think about that. Speaking of that, your post also confused me for a moment, because you where talking about Content Types, the HTTP header one, not node types ;) (My initial thought was, "WTF, per-bundle render controllers?" ;)
Comment #58
moshe weitzman CreditAttribution: moshe weitzman commented#53: entity-render-controller-1026616-53.patch queued for re-testing.
Comment #59
moshe weitzman CreditAttribution: moshe weitzman commentedOK, all feedback was incorporated and tests pass. lets move this along.
Comment #60
sunThis looks excellent, awesome!
I only have a few nitpicks, which can be happily adjusted post-commit:
?
Unnecessary $build?
Let's create a major follow-up task for this?
Comment #61
webchickWhile this is currently classified as a feature request, and thus subject to thresholds, which we are currently over, I think like #1723892: Support for revisions for entity save and delete operations I consider this more refactoring than a new feature, so I'm re-classifying as a task.
My goodness, that looks so much nicer.
Like sun, I also have no idea what this is doing.
Unlike sun, I don't think renaming theme functions and arguments deserves a "major" status. This code works just fine without it, and it's not worth blocking other features on this kind of clean-up. But yes, let's create a follow-up for that, as well as the taxonomy_term one.
Committed and pushed to 8.x! This will need a change notice.
Comment #62
yched CreditAttribution: yched commentedFYI, might be of interest to the participants of this thread : #1812720-3: Implement the new panels-ish controller [it's a good purple]
Comment #63
webchickWe're once again over the critical task threshold. Please try and find time to write up documentation for your API change ASAP so your fellow contributors' features aren't blocked. Thanks.
Comment #64
xjmHere's a start on the API changes for the change notice:
Added to
hook_entity_info()
.Removed API functions.
Added functions, classes, and interfaces.
Comment #65
xjmMight as well.
Comment #66
xjmChange notice filed. Leaving open for the followup -- I'd suggest opening a new issue? It's not clear to me from the (lack of) summary or from the recent comments what specifically needs followup, so I'll leave it to someone else to file that issue and then mark this one fixed.
Comment #67
andypostIs this still open because of waiting a follow-up for theme clean-up?
Comment #68
fgmi think that's more about the "render controller per content type" suggested by linclark in http://drupal.org/node/1026616#comment-6567612
Comment #69
BerdirYes, I think it just needs a follow-up for the clean-up and theme variables. The per content type stuff is currently being implemented using Serializers.
Comment #70
fagoI'm not sure about what the cleanup is supposed to do exactly, could you open a follow-up explaining it Berdir?
Another follow-up we should do:
#1067126: Support rendering entities in page mode
Comment #71
yched CreditAttribution: yched commentedNotifying the fine folks in this thread : #1852966: Rework entity display settings around EntityDisplay config entity - thanks to the generic render controller, we can unify how display settings for the various components (field, 'extra field', contrib stuff like field_group) are stored.
Comment #72
BerdirOpened #1857324: Use default theme name and entity key in $build for user entity and #1857336: Use entity variable in $build for taxonomy_term entity. marking as fixed.