[meta] Make entity view mode row style the preferred way to build a view (with feature parity for site builders)

YES OMG YES!

\o/ \o/ \o/ \o/ \o/

+1 on the overall idea of merging the two "entity output" APIs.

One conceptual difficulty is that entity displays are per bundle, and views are cross-bundles.

Also : note that internally, "field row style" views actually build an EntityDisplay object at runtime - one per bundle in the result set - and use that to trigger actual formatter rendering.

Well, the discussion we have to add is: How do we deal with aggregation queries ... they fundamentally just work on fields.

One conceptual difficulty is that entity displays are per bundle, and views are cross-bundles.

Well, I don't think this is a problem. As the issue says, this is about view modes, not view displays ...

Afaik we should rather make an issue to deprecate the crazy rewrite functionality inside views and move into its own module.

"Entity view mode row style view displays" is a lot of nouns in a row.

So many even that I don’t understand what's being proposed here :-) I suspect it breaks down like this:

Entity view mode

row style

view displays

But not sure how those play together and thus unclear to me which interactions and flows are at play here.

Let's use correct terminology

It's not possible to more than 100% agree, but I created a stub issue since I like the idea so much #2676848: [PP-?] Move Views field rewrite functionality to a separate module and deprecate it.

Thanks for visualizing @xjm, that helps a lot.

So for the interaction design part this is an opportunity to redesign the taskflows that can occur in these "Format" and "Field" sections, right?

Let's start with small steps and get #2677030: New views should use the view mode row plugin done.

One thing we really need to talk about is IMHO not only the way to design the normal usecase of views, which is listing a bunch of entities.
How would we replace the list styles, which are not just a list of entiies:

• Tables
• Aggregated queries
• External data which doesn't return entities

While this sounds super technical, those kind of usecases are the reason views is tricky.

While I agree that “Entity display” should be the default, I would be very sad if the fields mode, with its powerful rewrite functionality, goes away, because I don't see entity display mode getting the same level of detail, and the “wrap the term name in a h4, leave out the label for the title, and wrap the whole thing in an aside tag” is insanely useful, and much quicker than having to override 3-4 different templates, as you would have to do otherwise.

Well, I think making the field more deprecated is not possible, if we still consider it as useful and not just vanishable.

@mikl
Yeah, I totally agree and people love that they can tweak a little bit of the output using the UI. On the other hand there is a certain kind of frontend people which totally dislike this feature. In general the problem is to actually figure out what the personas are we deal with and what their usecases are.

Have we thought about views as a report building tool? This is the vast majority of what I find I use views for, pulling multiple fields from multiple entities via joins, often aggregating or calculating on results.

I'm not sure entity displays will ever be able to support that?

I understand the desire to remove the complexity of it for sites that don't need it or not have it by default, but deprecating/removing support for it feels like a major step backwards for Drupal as a framework for applications etc.

We have two major use cases: 1) reporting tool 2) entity listing tool.

They should probably not share a UI, nor most of the code.

Glad to see this direction being considered, one of the hopes when introducing EntityDisplays in D8 was that they could be a step to help narrow the gap between "regular entity view" and View's own field display features.

It's true, though, that "entity view mode" row styles might still be a bit short to cover the needs of admin listings, notably those picking various fields from various entities through relationships.

Actually, if "by field" row styles move to a separate codebase, do we still have a case for relationships in the main codebase ? Sure, relationships can also be used for filters and sorts, but not sure that's really useful with an "entity view mode" display style (which only ever displays the primary entity and won't ever show anything about the relationships, right ?)

This is the thing, as yched started, we basically create two codebases, of which one will be really hard to maintain if we move it back to contrib. IMHO this is a critical decision, because it moves away power from the sitebuilder, which is IMHO THE strength of Drupal.

@yched
Regarding relationships, many usecases are actually not at all about rendering but about filtering.

Regarding relationships, many usecases are actually not at all about rendering but about filtering

Sure, it's just that the actual use case for a view using "entity" row-style and having relationships on its filters / sorts, seems possibly a bit narrow (since the values from the relationships, that were used to sort / filter, cannot be part of what gets displayed, so it's just internal filtering)

But yeah, I guess splitting out relationships too would needlessly add to the "two codebases" burden you mention anyway. Never mind :-)

How to enrich EntityDisplays regarding entity_ref fields is an interesting topic though. Currently you can configure the output of your e_r fields in the EntityDisplay using e_r formatters that either :
- display the referenced entity in a given view mode (will appear "nested" in the output of the parent entity)
- (with a contrib formatter) display some specific field in the referenced entity using some specific formatter + settings for that field.

The latter is more like what View's current "by-field" row style lets you do with relationships, but with the limitation that you can only use that to display *one* field on the referenced entity. That's because an EntityDisplay currently only lets you specify one formatter for a given field : a field is either displayed (once) or hidden, which keeps an easy 1:1 mapping between field names and entries in the resulting $entity->view() render array and subsequent entity templates.

So you can configure your e_r field on the parent entity to display field_a on the referenced entities, but if you also want to display field_b, you're stuck.

Being able to display the same field several times with different formatters/settings is a long-time idea, that would be super handy if we want EntityDisplays to replace most uses of "by-field" Vews, but it's probably not a super trivial evolution. Internal code aside, it basically means we'd need to bring more or less the current Views UI for "adding fields to your by-field row plugin", into the "Manage Display" entity screens...

@yched - one way around that is to make use of Panelizer to build your entity display. Not sure how far they are with D8 support, but I do this in D7 to do this exact kind of thing (and leverage the benefits of row caching etc). However, Panelizer will probably be a lot harder to integrate with things like a table style etc...

On the subject of relationships, wouldn't doing things like table sorting on author based on name rather than ID require relationships? Or being able to filter by author name?

Perhaps a good way to move this forward would be getting a list of features and categorising them by the 2 main use cases (entity lists/reports - or neither :P) - then we can find out what common functionality we need (and hopefully code) and figure out how to separate out the bits that aren't common.

Reducing the complexity of views UI and making field display use Entity Field API would be a great win for both use cases!

+1

@xjm
Okay fair, but the issue summary still says something different, IMHO :)

Well, effectively a deprecated feature is something you are no longer supposed to be used. Having aggregated data is not only useful for non-entity data.
I guess its just me being not able to understand the plan properly, so please ignore me.

Maybe we should also not provide feature parity. IMHO we could talk about which parts could be moved away from the configuration layer into the theming layer, as many options are clearly theming related. Maybe all those options are just a sign of bits and pieces which are hard in the theming layer.

I was also taken aback by the "deprecated" phrasing. Had to read down all the way through this to understand that no, you're not actually planning to remove views field formats. I think summary could use clarification there.

Thank you xjm!

What effect does deprecating have on support? E.g. If there is a bug in a deprecated field handler but switching to entity view modes isn't an option. Does that become won't fix as it's deprecated?

For now I would suggest to not deprecate it but rather prefer it. The entire discussion of deprecation can actually just be done, if it was moved out into its own thing.

The question of aggregated (and possibly non-entity) queries seems the hardest that we don't have a clear solution for yet.

@yched in #24 points out that we can get some of the way using entity reference fields. It seems we need to specify the aggregated use cases we're trying to support and figure out if the entity view modes with entity references could be extended to cover them.

3 questions come to my mind:

1) entity references could perhaps be extended to allow tokenised references to things like "current user". Are there any relationships that can be built now via views that couldn't be handled by entity references?

2) Could we handle grouped queries using view modes and entity references?

3) Could we have "count" etc. formatters or similar for entity reference fields in order to generate aggregate results? We'd need to allow filtering & sorting so as to get "COUNT WHERE" etc.

If entity references can't go all the way, one possibility might be to have a kind of entity in the system called "Aggregate" whose instances can be configured and used in a view, but is constructed out of content entities and stores no content itself. So we'd define a new "Aggregate" similar to creating a new content type: select the relationships that define it, pick fields from the constituent entities, manage view modes; and then in Views just choose that Aggregate entity as the base of the View.

@bojanz #2665694-19: [meta] Make entity view mode row style the preferred way to build a view (with feature parity for site builders)

I'll add a third one to that: bulk operations and editing tool (the latter at least in D7 with Editable Views and/or Editable Fields).

I look at Views as a query builder that gives me a set of data that I can do something with - edit, export as csv, show as a list, whatever). In my opinion it is very dangerous to assume that this set of data will always be entities.

For instance, I've had a situation last year where I've taken a multivalue checkbox field, displayed its values as separate columns of a table and coupled it with javascript to make a user-friendly switchboard. At the same time, I've used views to provide raw information from a number of different entities that helped me perform a complex calculation, display results and provide input fields (through editable fields) that recalculated the results in real time.

I mean, sure, both of those would be doable without views - but why, if the tool exists?

View modes of entity is good, cool and usable.

But, I experienced problems when entity had too many view modes.
It causes some panic to site builder. Also site builder can make many views. (for large site or views has many display)
Also, some cases mix entity fields and other programatically generated components.

At least, I think row plugin is usefull for some complex cases.