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.Problem/Motivation
Given how views listings work, EVD is not a perfect fit. It is not only per entity but also per bundle.
This was mostly done, due to the fact how the field UI is created and you configure the rendering of a specific bundles,
but for views, you don't do things necessarily
Proposed resolution
- Keep the way how EVDs are stored
- Keep the UI
- Just change EVD internally to support rendering fields across entiies
Comments
Comment #1
yched CreditAttribution: yched commentedCopy pasting myself from #1867518-112: Leverage entityDisplay to provide fast rendering for fields :
Comment #2
larowlanWim proposed something similar a long time ago for a comment issue, will try and find it
Comment #3
Wim LeersYes, that's the "discussion at Drupal Dev Days Szeged with swentel" thing I referred to in a comment a few days ago.
Comment #4
Wim LeersI just finally found that issue that #2 and #3 refer to: #2227383: EntityViewBuilderInterface::view() should accept an EntityViewDisplay, not only a view mode ID.
Comment #5
yched CreditAttribution: yched commentedI guess the major thing is that the Formatters still need to be instanciated (and thus, persisted in the EVD) by bundle, since they receive the FieldDefinition, which is by bundle.
Doing this came was rasied in earlier steps in #1867518: Leverage entityDisplay to provide fast rendering for fields as a possible way to mitigate the overhead of an approach using EVDs compared to an approach bypassing them. However, the difference didn't seem that big in the later comparisons in #183 and below over there.
Unless it does make a noticeable difference for per-field Views (which will get row caching anyway ?), I can't say I'm too keen on bending the internals of EVD too much away from their main use case (an EVD is for a bundle).
Is there a way we can try to predict how much that change would benefit Views ? Looks like this would mostly save the creation of one EVD per bundle, so maybe we should check the wall time of EVD::create() there ?
Comment #6
Fabianx CreditAttribution: Fabianx commentedI think the better benefit is to re-use this issue to allow aliased fields and less cross-bundle rendering (which did not work). That could remove quite some complexity from the views code IMHO.
Comment #7
yched CreditAttribution: yched commented@Fabianx: yes, aliased fields (i.e EVD supporting rendering several times the same field) is still interesting IMO, and could be worthwhile in the future for the "main use case" (entity_view()) as well. That's a separate topic though, so I'd rather open a separate issue though, else the OP and first comments here would be totally unrelated. Opened #2483095: Consider adding support for 'field aliases' in EVD (allow an EVD to render a field several times) for that.
The question in #5 is then - do we "won't fix" this issue here ?
Comment #16
Pasqualle