Problem

  • function views_get_view($name) {

    + many similar Views API functions.
    + Naming the module that does the work of this module "views" is very confusing for people who come from general web development background, MVC development backgrounds, and other CMS systems. To them "View" is synonymous to "Display" which is not was the "views" module does.
    + The true purpose of the views module is to be a Query generator + Display handler of these generated queries. None of which is evident from the unassuming name "views"

    Future Use

    By targeting Drupal 9, we have time to evaluate the role of this module. Views was ported to Drupal 8 and included without changing it's focus. Does View's purpose make sense for Drupal's future. Should it continue to govern the structure and appearance of collections of nodes and other data? Should we refactor it's architecture and separate it's responsibilities into smaller and more focused components?

Goal

  • Consistency.
  • Discuss the future purpose of this module, it's scope of control and impact

Proposed solution

  • function view_load($name) {

Related issues

Suggested Names

  • Collections
  • Lists
  • SQL Views
  • Query

Comments

tstoeckler’s picture

tstoeckler
he/him
Primary language German
Location Essen, Germany
commented

Generally +1 on singular module names, but this one comes with at least a small can of worms.

1. We already have the concept of view modes, and we want to decouple that from the entity info so together with this issue we might have something like

function view_mode_info($entity_type);

and

function view_load($name);

Which have absolutely zero to do with each other.
And even worse:

$view_modes = view_mode_info('view');

Now I've heard Bojhan suggest that view mode is actually not the most intuitive term of all, and considering that we will soon have "Display" and "Template" and what not, we might actually end-up renaming view modes to something else, but I don't think we can bet on that at this point.

2. I think the difference between

entity_view_multiple($published_sticky_nodes);

and

view_load('published_sticky_nodes')->render(); // I don't know if it's actually called render(), but you get the idea...

is going to be a tough one to sell to developers.

All that said, we sort have already have part of that confusion with "views" already, especially "views" vs. "view_multiple", so I am still tentatively +1 on this, but I wanted to point out that this is by no means as trivial as renaming a theoretical comments.module to comment.module or whatever.

EDIT: Fix example code

tim.plunkett’s picture

tim.plunkett
he/him
Primary language English
Location Philadelphia
commented

Most of our class names are singular already, I think with the exception of ViewsBundle since that has to match the module name :)

That said, this might be a lot of work for little gain.

yched’s picture

yched commented

IIRC, the name "Views" was more related to the notion of "SQL views" rather than "the act of viewing" (in the sense of displaying / rendering), which is what the other core uses of the term (entity_view(), view modes...) refer to.

Probably a poor argument, but that's what the plural in views.module reminds me of : views.module is about views (the noun), more than viewing (the verb).

As a side note, I'd be a little sad if those other (much more intuitive & legit IMO) uses of 'view' as in "displaying" had to move over because we decide that the term should be reserved to an advanced SQL notion :-)

sun’s picture

sun
Primary language German
Location Karlsruhe
commented

mmm, yeah, "view" is also ambiguous with "view" in MVC. "views" is too.

Unless I'm mistaken, then the current Views is no longer related to SQL in any way - it's able to query data for any kind of resource set, as long as it knows how to query it.

Technically, Views module is actually a List module. It's about data listings, in all possible ways.

But "List" in particular is moot already, since it's a reserved keyword in PHP and the reason for why we had to do #1592632: Merge List field types into Options module

klonos’s picture

klonos
he/him
Primary language English
Location 90% Melbourne, Australia - 10% Larissa, Greece
commented

How about query.module then?

dawehner’s picture

dawehner
Primary language German
commented

One point we might should have in mind is that there are already tons of people out there which know the name "views" and could be confused by fancy stuff like "lists", "query" whatever.

In general the querying/listing stuff is just one part of the module, the actual rendering, styling and all the custom plugin logic on top of it is the reason why people prefer it over all these simple solutions.

In general I agree with tim that we should put the effort into making the module better, not renaming it.

dawehner’s picture

dawehner
Primary language German
commented
Status: Active » Postponed

At least 4 of 4 VDC team member agreed that this is not worth to do for Drupal 8. Let's better move that to Drupal 9 and maybe discuss another module name in general.

sun’s picture

sun
Primary language German
Location Karlsruhe
commented
Status: Postponed » Active

There's no reason to postpone this just yet. The only argumentation against "view" thus far has been "work", but if someone would do the work, that argument would be obsolete.

Speaking of, since the majority of the Views code is based on plugins, I actually do not think that renaming it is the "monster effort" that we're generally presuming here. Alas, I think a patch to do so can even be generated by a bash script, and we should look into that.

Right now, the majority of the Views module code even uses identifiers + IDs + classes + whatnot that are outside of its namespace; namely, "view".

Add to that... functions like views_get_view():

function views_get_view($name) {
  $view = entity_load('view', $name);
  if ($view) {
    return $view->get('executable');
  }
}

Not exactly the common API we have in core right now. view_load() would be much more straightforward.

However, for the scope of this issue, I'd personally expect that all of these would simply be turned from "views" into "view" only; i.e., view_get_view(). A clean-up of the resulting functions would be left to follow-up issues.

moshe weitzman’s picture

moshe weitzman commented
Status: Active » Postponed

Not just work for to write this patch, it is work for every one who has written code that integrates with views. It is work for everyone who rote documentation for views. I think this is a case where backward compat is more valuable than consistency. For me, this is Won't Fix but I'll defer to the wishes of VDC team.

xjm’s picture

xjm
she/her
Primary language English
commented
Version: 8.x-dev » 9.x-dev
cosmicdreams’s picture

cosmicdreams commented
Title: Rename views.module to view.module » Rename views.module

Also will update title with the suggestions given in the comment thread.

cosmicdreams’s picture

cosmicdreams commented
Issue summary: View changes

Updated issue summary.

cosmicdreams’s picture

cosmicdreams commented
Issue summary: View changes

Updated issue summary.

catch’s picture

catch
he/him
Primary language English
commented
Version: 9.x-dev » 8.3.x-dev
Issue summary: View changes

If we're going to do this at all, we should do it in 8.x with a bc layer (yes it would be horrible). Or we should won't fix it.

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.

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

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.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.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.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.6.x-dev » 8.7.x-dev

Drupal 8.6.0-alpha1 will be released the week of July 16, 2018, which means new developments and disruptive changes should now be targeted against the 8.7.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

jibran’s picture

jibran
he/him
Primary language Urdu
Location Toronto, Canada
commented

If we still want to do this then we have to add BC in 8.x so that it will allow people to move till we break BC in 9.x.

longwave’s picture

longwave
he/him
Primary language English
Location UK
commented

This feels like renaming for the sake of renaming. There doesn't seem to be a convincing argument for a new name - "view" is still ambiguous - and the BC layer for this will be hideous. Just like "node" has a specific meaning in Drupal I am pretty sure that "views" has a specific meaning now, and most people are ok with that.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Status: Postponed » Closed (won't fix)

Agreed with @catch, @Moshe, et. al.