Problem

When a site builder creates a content type it is highly likely that they will want an entity reference view for that type.

For example if I create a type "Address" I almost certainly want to reference that type in "location" or "Event". Similarly if I create a type "Song" I almost certainly want to reference that with a multi-value reference field in "Album". When you think about it the mere fact that I am creating a "type" ie. an entity of which there will be more than one, implies that at some point I will want to show a list of those things.

The only cases I can think of where an entity would not require a view are ones where core has already provided a view (content, files, recent content, recent comments etc.).

Proposed solution

When a site builder creates a content type they should see a "View settings" tab in the vertical tabs with the option "Create an entity reference view" checked by default, and the descriptive text: "With an entity reference view you can attach content of one type to content of another type. For example a type "song" with an entity reference view could be attached to a type "Album" by adding an entity reference field."

Comments

tkoleary created an issue. See original summary.

swentel’s picture

Component: field system » entity_reference.module

I don't fully get it since entity reference has this functionality and you don't even need a view for it ?

amateescu’s picture

Agreed with @swentel, it's quite easy to create an entity reference field that references a certain content type without the need for a view specific to that content type. Maybe we're both missing something here? :)

dawehner’s picture

Okay, so entity_reference maintainers disagree.

Let's bring some more disagreement from views as well. As a site builder, I want things to be explicit, not explicit, behind the scene. Just imagine you create some field,
the view is added automatically in the background and booom you have some security issue on your site, because this data was rendered somehow.

All this kind of black magic stuff is just wrong, IMHO

damiankloip’s picture

Yeah, also agree this does not really make too much sense. You could end up with tons of views you don't want without realising. This would also open up a can of worms with regard to configuration of that view. You would need something similar to the views wizard?

Sounds like this is one to close?

dawehner’s picture

Status: Active » Closed (works as designed)

Let's close that.

tkoleary’s picture

@dawhener

All this "black magic stuff" is also sometimes referred to as "Usability." :)

But on a more serious note, I'd be fine making the option unchecked by default (though I would prefer the reverse) which I think resolves the question of "stuff happens in the background that may cause me problems in the future."

@amateescu

Re:

Agreed with @swentel, it's quite easy to create an entity reference field that references a certain content type without the need for a view specific to that content type. Maybe we're both missing something here? :)

What you are missing is that the common use case is not what entity reference provides OOTB, which is just a list of links, but a full view of rendered entities. For example, in the case of albums and tracks what I want on the Album node is a view of tracks where each track has the track name, number and duration as well as an audio file with a play button. For that I must create an entity reference view, correct?

@damiankloip

Yeah, also agree this does not really make too much sense. You could end up with tons of views you don't want without realising.

Tons of views? On average how many content types have you seen in even the largest of sites you have worked on? 20? 30? I personally have never seen a site with that many. Keep in mind that I'm not talking about every entity type here, just content types. This obviously does not make sense for terms, custom blocks, etc.

As for "without realizing" see above. Unchecked by default is fine as long as we have some clearly worded explanation of why you would need this.

amateescu’s picture

Status: Closed (works as designed) » Active

For example, in the case of albums and tracks what I want on the Album node is a view of tracks where each track has the track name, number and duration as well as an audio file with a play button. For that I must create an entity reference view, correct?

Yes, that's correct :)

I think the "enabled by default" part is what most people who commented here didn't like, but if you are ok with having it unchecked by default, I don't see any reason not to do this.

There are a few small things that should be discussed before starting a patch though, for example: what happens to that view when the content type is deleted? Should we delete it automatically? What if it's also used in other places as well, maybe even with some additional displays?

dawehner’s picture

@tkoelary

But on a more serious note, I'd be fine making the option unchecked by default (though I would prefer the reverse) which I think resolves the question of "stuff happens in the background that may cause me problems in the future."

Cool. Can we agree to not make a special UI for nodes though?

But on a more serious note, I'd be fine making the option unchecked by default (though I would prefer the reverse) which I think resolves the question of "stuff happens in the background that may cause me problems in the future."

We are just optimizing for some arbitrary unknown user here. Making this explicit instead of implicit, explaining people what happens so they are empowered to do more is my philosophy,
because well, it allows users to jump over the local optima and find a good global optima.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.0-beta1 was released on March 2, 2016, which means new developments and disruptive changes should now be targeted against the 8.2.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.2.x-dev » 8.3.x-dev

Drupal 8.2.0-beta1 was released on August 3, 2016, which means new developments and disruptive changes should now be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jonathanshaw’s picture

What you are missing is that the common use case is not what entity reference provides OOTB, which is just a list of links, but a full view of rendered entities. For example, in the case of albums and tracks what I want on the Album node is a view of tracks where each track has the track name, number and duration as well as an audio file with a play button. For that I must create an entity reference view, correct?

By picking a "Rendered entity" formatter for the entity reference field and choosing a view mode in the formatter settings, you could display the track name, number, duration and play the audio when VIEWING an album. What you can't do without involving a view is filter the tracks displayed, or show any of these fields as part of the widget when EDITING the entity.

@tkoleary could you clarify whether the "common use case" you envisage is when viewing or editing the hypothetical album? The viewing case does seem to be the 90% use case.

tkoleary’s picture

@jonathanjfshaw

@tkoleary could you clarify whether the "common use case" you envisage is when viewing or editing the hypothetical album? The viewing case does seem to be the 90% use case.

You are correct. The 90% use case is viewing the entity. If we look at this from the users perspective and completely ignore all questions of implementation I'd phrase it as:

"When I build a site and I create a content type, in most cases I want to also show a list of that content somewhere else on the site, I would like to see an option to create that list automatically using sane defaults when I create the type, so I don't have to both figure out how to do that, and then go through the process of manually doing it every single time I make a new content type."

That may or may not require the solution an entity reference view, but entity reference would seem to me to be the method that would offer the most configuration possibilities after-the-fact.

jibran’s picture

Component: entity_reference.module » entity system

Moving to right component

tkoleary’s picture

Priority: Normal » Major
Issue tags: +Usability, +UMN 2015, +sprint

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.