0

I am having trouble understanding how Views fit into the Drupal 7 object model. (I've seen responses that Drupal doesn't have an object model but since it is a computer program, I am not at all buying that.)

At the end of the Views UI it asks if I want to create a block to go with my view (or is it that the View I'm creating IS a block?). This seems like a classic case where a convenience function (creating a block as a side-effect of creating a view) might be handy but makes it hard to understand what's really going on.

I know a view is a content query. That part seems pretty straight-forward. It is the mechanism by which the content gets added to a block, a page, or what else? Is a view a query that lives within these objects but doesn't have a life of its own?

I am NOT looking for an operational explanation or a tutorial on how to create a view. There are plenty of sources for that kind of info. Instead I am trying to understand views from a data structure and object model point of view. Any links to relevant explanations would be helpful. I've spent hours searching and have found nothing very satisfying.

1

A View can (very basically) be considered a 'list of data'. There are various interfaces to let it know what data to display, and how, but the idea behind a View is simply to get a list of data from somewhere and get it out to the screen. It executes queries, but is not itself a query.

At its heart a View relies on a single 'base table' to query against. It can pull in data from different tables as long as relationships are appropriately described in code, but can only operate on one base table at a time.

These base tables are described to Views using hook_views_data(). The Views module comes with implementations for all core entities (node/user/taxonomy term), and many contrib modules that define custom entities provide Views support (the Entity module can help there too). But it's not limited to content, or even entities, Views can display data from any table it knows about.

A View contains one or more displays (e.g. page, block, rss feed, etc.), which are responsible for augmenting the database query and providing format/meta/other contextual information that is needed for the query and rendering processes. Each View has a default "master" display that newly added displays will inherit from.

Views uses information from these displays to hook into various things. For example, Views implements hook_block_info() and hook_block_view() in order to let Drupal know about the blocks that have been created as displays for all Views. That's why when you create a block in Views, you'll see it available straight away for use in the block admin page. Something similar happens with hook_menu() for pages/rss feeds.

Sorry if some (or all) of this isn't what you were looking for, this is a bit of a brain dump; wasn't sure exactly what you needed to know.

  • I understand that "view" is named according to the RDBMS use of the term. It extracts data (possibly a subset) from a 'base table' and presents it to the rest of the world in a transformed manner with 'displays' helping in this process. But what objects own a view and what objects does a view own? When you say 'block view' is that a view that refers to a block or a block that refers to a view? Or is the relationship 'contains' rather than 'refers'? I am amazed that no one ever presents an object model for a piece of software as complex as Drupal. – Paul Topping Oct 20 '14 at 18:52
  • The Views module would be the closest contender for owning the View I think. Until you add on contrib modules that's the only code in the system which does any sort of management in relation to the Views themselves. I suspect Displays are the only objects a View could be said to own. – Clive Oct 20 '14 at 18:59
  • I think it depends how you look at it - the block definitely contains the view, it's just how it gets there. The Views module tells the Block module that there's a block available by way of hook_block_info(), and the Block module asks the Views module for the block content by way of hook_block_view(). I'm not trying to be obtuse, Drupal is AOP and I'm not sure how to apply its architecture to what you're looking for – Clive Oct 20 '14 at 19:10
1

See Clive's answer about how views module hooks into the blocks, pages, etc. I rather thought you are looking for "How come Views is object-oriented, and has classes, while other Drupal functionality is mostly procedural code.

The best way to start the answer is probably by explaining a View instance. view object

See that, each "View" is actually an instance of view class. This class is the base class of all views. Modules do not extend or implement this base view class.

Furthermore, Views module, at least until Drupal 7.x-3.x, do not use all object-oriented functionality. You will not see interfaces or abstract classes to enforce specific methods or properties, but the convention is extend a parent class. You could create a completely new handler or plugin without extending or implementing any other class.

You will note name, description, tag, base_table, etc are basic properties of the View. These values are directly stored in the views_view table.

Then, each View can have one or more displays. Now that we are talking about displays keep in mind that every block, page, attachment, RSS feed, slideshow, map, etc is technically a plugin of type display.

Views module comes with basic displays, such as block, page, that Views module provide classes for. Modules can introduce new plugins by implementing hook_views_plugins.

There are other types of plugins, such as pager plugin, style, query, etc. In the Views module folder, take a look at the available plugins in ./plugins folder.

These plugins simply introduce new functionality: for example, create a slideshow from handlers, show rows in a map, create block content and a subject, check access, etc. When a module is introducing a new query, chances are most of the core logic already exists in the default query plugin class. Modules can simply extend this existing class and make adjustments in the new class of its own.

These plugins are not responsible about the actual data. This is where handlers come into play. A handler is basically, a set of instructions on how to handle a field, filter, argument or a sort criteria".

Handlers are responsible about actual data and instructions on how to handle data. Each and every field, filter, argument or sort criteria known to Views has a handler class. Views module comes with simple handlers for each of these handler types.

These basic handlers include handling a field as a number, using an IN query for node table's type field, a node ID argument, sorting rows by the node created date, etc.

Node ID and created date both fields are integers in the database. But, in the Views UI, you can configure which date format you want to display the created date in, but you can't do it for the node ID. Notice the difference here. Node ID column is handled by some class, and it is not the exact same as the handler responsible for node created field. However, you will notice some similarities in both fields.

See views module folder's handlers folder for views-provided handlers. Again, modules do not need to introduce new handlers to the View, but they must be available in the run time (this is taken care by Drupal class autoloading with .info file).

In hook_views_data, you can define which filters must be used to handle a particular table column. Views will then call query(), render() and other methods of the specified handler class and perform that action. If your table column's data type can be handled with an existing class, you simply define that existing class. Otherwise, you can create new handle, ideally extending an existing one that is the closest to what you need, and make adjustments to it. I used "ideally" here, because it's not necessary to make the classes an implementation of another class, but they must have methods to satisfy the plugins used in the View.

  • This is getting a lot closer. Each view contains a list of display records as shown here. Are the display records shared among multiple views or does each view have its own private list? Does each display record refer to a page/block/feed/... object or is it the page/block/feed/... object itself? – Paul Topping Oct 20 '14 at 22:36
  • Display records are not shared in between Views. They are objects, but are not operable by its own. Parent view class handles everything. – AyeshK Oct 20 '14 at 23:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.