{"id":2036,"date":"2019-07-29T07:00:59","date_gmt":"2019-07-29T07:00:59","guid":{"rendered":"https:\/\/understanddrupal.com\/?p=2036"},"modified":"2022-04-24T05:54:07","modified_gmt":"2022-04-24T05:54:07","slug":"quest-ce-quune-vue-dans-drupal-comment-fonctionnent-ils","status":"publish","type":"post","link":"https:\/\/understanddrupal.com\/fr\/blog\/quest-ce-quune-vue-dans-drupal-comment-fonctionnent-ils\/","title":{"rendered":"Qu’est-ce qu’une vue dans Drupal? Comment fonctionnent-ils?"},"content":{"rendered":"\n

In Drupal, a\u00a0view\u00a0<\/strong>is a listing of information. It can a list of nodes, users, comments, taxonomy terms, files, etc. A view scans your website using any criteria you specify and presents the results in the format of your choice. Example formats include a HTML table, a RSS feed, a PDF document, a CSV document, an interactive map, an image slideshow, or a JSON representation to be used as a REST endpoint. The same content can be presented in multiple formats at the same time. For instance,\u00a0you can\u00a0present a table of user information and on the same page a link to download the data in CSV format.<\/p>\n\n

Let\u2019s continue our journey to understand more Drupal concepts. As you might have already noticed, they build on each other. Today, you will learn how\u00a0nodes<\/strong>,\u00a0content types<\/strong><\/a>, and\u00a0fields<\/strong><\/a>\u00a0can be used as part of views configurations. Also, you will find examples of\u00a0blocks<\/strong><\/a>\u00a0that are created using views.<\/p>\n\n

Understanding Views terminology<\/h2>\n\n

There are\u00a0three\u00a0key terms that you need to be aware of: the\u00a0Views<\/em>\u00a0module, the\u00a0Views UI<\/em>\u00a0module, and a\u00a0view<\/em>\u00a0instance. The\u00a0Views<\/em>\u00a0module is the engine of the whole system. Often described as a\u00a0SQL query builder, it allows you to fetch data stored in Drupal\u2019s database, assemble a list of results, and present them in various output format. One of the great benefits it provides is that site builders do not need to know SQL or details about the underlying database structure. Having a basic understanding of Drupal concepts like nodes, content types, and fields suffices in most cases. Using the\u00a0Views UI<\/em>\u00a0module it is possible to create\u00a0view<\/em>\u00a0instances which encapsulate the configuration of what elements to display and how.<\/p>\n\n

The\u00a0Views UI<\/em>\u00a0module is the visual user interface of the system. It offers a setup wizard that guides you through the process of creating and configuring a view. Once all the views for a site have been created, the Views UI module can be\u00a0uninstalled\u00a0and the individual view instances will continue working. For one, you gain a bit of performance as there is less code to execute on page loads. But more importantly, editors will not be able to modify the\u00a0views\u00a0configuration using the administration interface in production environments. Site builders will be able to continue making changes in development environments as needed.\u00a0Then, they can push the changes\u00a0as part of their normal configuration deployment strategy.<\/p>\n\n

A\u00a0view<\/strong>\u00a0instance is a set of\u00a0configurations\u00a0that describes how data in Drupal will be collected and presented to the site\u2019s visitor. A single view can have multiple\u00a0displays<\/strong>. Possible view displays include a\u00a0page<\/em>\u00a0available\u00a0under certain\u00a0URL\u00a0path<\/em>, a\u00a0block<\/em>\u00a0to be placed in a\u00a0theme region<\/em>, or a\u00a0feed<\/em>\u00a0to be exported in\u00a0RSS<\/em>\u00a0or\u00a0OPML<\/em>\u00a0formats. Each type of display will allow you to specify\u00a0a presentation\u00a0format<\/strong>. Possible values vary per\u00a0display<\/em>\u00a0type. In the case of a\u00a0page<\/em>\u00a0display, valid alternatives include\u00a0unformatted lists<\/em>,\u00a0tables<\/em>,\u00a0HTML lists<\/em>, and\u00a0grids<\/em>. Display and output formats are provided by modules. As you enable more core modules or install new contributed modules, you might get more options. Visit this page for a\u00a0list of modules that extends Views functionality<\/a>.<\/p>\n\n

Tip:<\/em>\u00a0The Views UI contains some inconsistencies that might confuse you if you are not familiar with it. One is that it uses the word\u00a0\u201cContent\u201d<\/em>\u00a0to refer to\u00a0nodes<\/em>, like in the first page of the views creation wizard. Another is\u00a0that,\u00a0contrary to the \u201cURL alias\u201d setting in the node edit page, the\u00a0path<\/em>\u00a0setting inside a view does not produce a validation error if it does not start with a \/ (slash) sign. These and other subtle differences exist, but they are negligible compared to all the benefits we get from using the system.<\/p>\n\n

Technical note:<\/em>\u00a0It is possible to see the SQL query that Drupal executes to fetch the list of results. Go to the \u201cViews settings\u201d page under \/admin\/structure\/views\/settings and check the \u201cShow the SQL query\u201d option of the \u201cLive preview settings.\u201d Then you can go to any view and upon clicking the \u201cUpdate preview\u201d button you will see the SQL query issued by Drupal. As an example have a look at the view that shows the frontpage configured under \/admin\/structure\/views\/view\/frontpage Note that table names are enclosed by curly brackets ({}<\/strong>). This is because Drupal allows you to define\u00a0table prefixes<\/a>\u00a0to share the database with other applications. Although\u00a0they is rarely useful<\/a>, it is possible to configure them. To accommodate for this, the Views API uses curly brackets to indicate that table names need to processed to prepend table prefixes when they are set.<\/p>\n\n

How do Drupal views work?<\/h2>\n\n

This section assumes the Views UI module is enabled. In order to create a view you visit the \u201cAdd view\u201d page under \/admin\/structure\/views\/add. For \u201cView settings > Show\u201d you need to specify which type of listing you want to create: content (nodes), users, comments, files, etc. You can also indicate how you want to present the results: a page with an optional RSS feed or a block. After this initial form you are taken to the complete setup interface where the configuration options are virtually endless. The initial selection for what to show (content, users, etc.) cannot be changed once set because it serves as the\u00a0base table\u00a0to collect data from. Except for that\u00a0and the\u00a0machine name<\/em>\u00a0of the view, every setting can be changed at any point using this interface. Instead of creating a view from scratch, let\u2019s review some examples that come with the standard installation profile in Drupal. This will allow us to better understand the Views UI interface.<\/p>\n\n

The\u00a0frontpage<\/em>\u00a0view is configured under \/admin\/structure\/views\/view\/frontpage. It comes with two\u00a0displays<\/strong>:\u00a0Page<\/em>\u00a0and\u00a0Feed<\/em>. The\u00a0Page<\/em>\u00a0will appear under the \/node\u00a0path<\/strong>\u00a0with a\u00a0format<\/strong>\u00a0of an\u00a0unformatted list<\/em>\u00a0show<\/strong>ing\u00a0Content (nodes)<\/em>\u00a0using the\u00a0Teaser<\/em>\u00a0view mode<\/strong>. Because we are showing a view node, there are no individual\u00a0fields<\/strong>\u00a0to present.\u00a0Using view modes is recommended over rendering fields. One reason is that it benefits from caching at the entity level.\u00a0The\u00a0filter criteria<\/strong>\u00a0section specifies the conditions that must be met by a node to appear in the final list of results. In this case, the node needs to be\u00a0published<\/em>\u00a0and\u00a0promoted to the frontpage<\/em>. Note that there is no filter criteria for content type. Yet, in a default Drupal installation all\u00a0articles<\/em>\u00a0appear in the frontpage and no\u00a0basic pages<\/em>\u00a0appear there. The reason is because, by default, articles are set to be promoted to the frontpage while basic pages are not. This setting can be changed on a node basis and defaults can be set on a content type basis.<\/p>\n\n

Back the the Views UI\u00a0for the frontpage view, in the\u00a0sort criteria<\/strong>\u00a0section we see two values. The first will put any node marked as\u00a0sticky<\/em>\u00a0at the top of the list. The second will order the nodes based on their\u00a0creation date<\/em>. When there is more than one sort criteria, the order in which they are defined is important. Any criteria that appears first in the list will take precedence over subsequent ones. This view display is used by Drupal\u2019s default frontpage. Note that its path \/node is set as the frontpage under \/admin\/config\/system\/site-information in a standard installation. The second display of the view is a\u00a0Feed<\/em>\u00a0whose configuration is mostly the same as the\u00a0Page<\/em>\u00a0display. The relevant differences are the path, format, and view mode\u00a0setting: \/rss.xml, RSS Feed format, and RSS view mode, respectively.<\/p>\n\n

Sometimes, we want to create a view to present a list of elements, but we want the end user to further filter down that list or change the way it is sorted. It is possible to do this using\u00a0exposed filters<\/strong>\u00a0and\u00a0exports sorts<\/strong>. A good example is the administration interface for all the nodes in Drupal that lives under \/admin\/content.\u00a0The configuration for this view is available at \/admin\/structure\/views\/view\/content.\u00a0This view presents seven\u00a0fields<\/strong>\u00a0in table format:\u00a0node operations bulk form, title, content type, author, publication status, updated timestamp, and operations.\u00a0In the\u00a0filter criteria<\/strong>\u00a0section, four elements have been\u00a0exposed<\/strong>\u00a0allowing the content editor to filter the list based on node title, content type, publication status, and language. This view does not offer any\u00a0exposed sort criteria<\/strong>, but\u00a0its\u00a0functionality and presentation is similar to that of exposed filters. However, because it uses a table format, some of the headers were made clickable allowing changing the order ascending or descending for that particular field. This is yet another way of allowing the end user override how the results are presented by default.<\/p>\n\n

It is important to note four things in the previous example. First, a\u00a0view field<\/em>\u00a0is not always\u00a0a\u00a0field attached to a content type<\/em>, like the one providing the \u201coperations\u201d column in the table. The reuse of the word \u201cfield<\/em>\u201d in this context is a bit unfortunate. Second, the list of fields in the\u00a0fields<\/strong>\u00a0section and the\u00a0filter criteria<\/strong>\u00a0section does not have to be the same. Third, the widget (text input, drop down, etc.) that will allow the user to filter down the list depends on the type of field that is being processed. Fourth, when the user filters down the list, the original presentation format is kept, a table with seven columns in this case.<\/p>\n\n

Tip:<\/em>\u00a0Drupal core comes with at least 14 default views. Studying them is a good way to learn more about how the Views system works. For the curious reader, have a look at the \u201cWho’s new\u201d and the \u201cWho’s online block\u201d views for examples of\u00a0block displays<\/strong>.\u00a0Both\u00a0are available at \/admin\/structure\/views. If you want to play with them without having to setup a local development environment, I recommend using\u00a0https:\/\/simplytest.me\/<\/a>\u00a0In that website you can test\u00a0Drupal core<\/a>\u00a0and contributed\u00a0modules<\/a>,\u00a0themes<\/a>, and\u00a0distributions<\/a>\u00a0within minutes.<\/p>\n\n

Technical note:<\/em>\u00a0Being a SQL query builder, some elements of the Views UI can be mapped to SQL concepts. The\u00a0fields<\/strong>\u00a0section maps to table columns to include in the\u00a0SELECT<\/em>\u00a0statement.\u00a0Relationships<\/strong>\u00a0add\u00a0JOIN<\/em>\u00a0clauses to the query. The\u00a0filter criteria<\/strong>\u00a0and\u00a0contextual filters<\/strong>\u00a0sections map to the\u00a0WHERE<\/em>\u00a0clause. The\u00a0sort criteria<\/strong>\u00a0section maps to\u00a0ORDER BY<\/em>\u00a0clause. The\u00a0pager<\/strong>\u00a0adds\u00a0LIMIT<\/em>\u00a0and\u00a0OFFSET<\/em>\u00a0clauses. Using\u00a0aggregation<\/strong>\u00a0adds a\u00a0GROUP BY<\/em>\u00a0clause to the query. And the \u201cDistinct\u201d\u00a0query setting<\/strong>\u00a0adds a\u00a0DISTINCT<\/em>\u00a0clause. Be aware that interface elements do not map one to one to SQL query elements. The Views UI strives to hide the complexity of the underlying data structure from site builders. Although not required, understanding this mapping is useful, especially when\u00a0the\u00a0view configuration does not yield the expected result.<\/p>\n\n

Dynamic results<\/h2>\n\n

Views is one of the many systems that allow you to create dynamic sites with Drupal. These sites that, once configured,\u00a0update their content automatically\u00a0as time passes. For example, if you have a website that contains information about events, you might want to have a page that lists only future events. To accomplish this you can create an \u201cEvent\u201d content type that has a \u201cdate\u201d field. Then you create a view with a filter criteria that uses\u00a0this\u00a0field so that only events whose date is \u201ctoday\u201d or greater appear on the final list. Note that it is possible to use date offsets as filter values. Once all the configuration is in place, content editors only need to add nodes and set a value for the \u201cdate\u201d field. When Drupal shows the page for this view, it will respect the original configuration and only show results that match the condition\u00a0from today onwards<\/em>. This illustrates the need to store node data in separate fields. This way you can use them as fields (to show), filter criteria, sort criteria, and more. If you had this information inside the \u201cbody\u201d field, it would be practically impossible to use it for these purposes.<\/p>\n\n

Views\u00a0with only one result<\/h2>\n\n

We said that views are used to create a listing of elements. When talking about lists, it is common to think of results with more than one element, usually many. But there are some cases where creating views of one element make\u00a0sense: when\u00a0you want to show \u201cthe most of\u201d, \u201cthe best of\u201d, or other superlatives. For example, the most visited article in the last month, the most attended event last year, the most recent product added to the store, etc. Another use case for a view of one element is when you want to show something random. To accomplish this, you add a single\u00a0sort criteria\u00a0aptly named \u201cRandom.\u201d\u00a0In all of these cases, the pager would be configured to show only one element.<\/p>\n\n

Other use cases<\/h2>\n\n

The use cases for Views are endless. Some will require the use of\u00a0contributed modules<\/a>, but it is possible to build many things with core Views functionality. Here is a very short list of things that you can built with Views:<\/p>\n\n