WissKI and Views for Developers

Drupal views is a bit of a Drupal in a Drupal. It has its own (entity) query, its own fields, ... This blog (part 1+2) helped me a bit to understand what's going on in views and how to implement views for a non-SQL-based entity type. Also, the EntityFieldQuery Views Backend module provides valuable code. Unfortunately, the D8 branch is currently defunct/not properly migrated.

At the moment, all of WissKI's integration code resides in the WissKI Core module and is two-fold:

• the class WissKIEntityViewsData.php which gives the definitions of the entity type and of all the fields available in views
• the classes under Plugin/views/*.

As you will notice, views is heavily plugin-based. Depending on what you are interested in you may look into the following files/dirs:

• WissKIEntityViewsData.php gives the definitions of the entity type and of all the fields available in views. If you want to add more (views) fields or change their handlers like filters, field displays, sort behavior, ... (sorting is currently NOT possible! ... but hopefully soon) NOTE: The definitions are cached and only re-read on cache clear.
• Plugin/views/query/WisskiIndividualQuery.php is the query plugin and the heart of WissKI's integration code that wraps the entity query and gathers the fields' values.
• Plugin/views/filter/* contains plugins for filtering entities (WHERE clause / entity query condition). Depending on field type different filters are necessary, e.g. for string or numeric data. All WissKI paths are currently handled by string filters.
• Plugin/views/field/* contains plugins for rendering single fields. Currently only a basic plugin for rendering paths is provided that handles multiple values. Otherwise, views' own plugins are used.
• Plugin/views/display/* contains a single plugin for integration with Drupal's REST API. Views' own REST display plugin cannot be used as it suppresses the query execution and thus yields false-empty lists. See also here.