#RVDA: Rewrite Views Datasource's Architecture

Motivation

As it stands right my company has forked the Views Datasource module because it's current architecture is not flexible enough to allow implementers to override all or some of it's field output.

Problem

Currently Views Datasource is hardcoded to use the the default Field API formatters that come with each field. I've spent enough time researching this issue and talking to the likes of @merlinofchaos (he must hate me at this point) to conclude that the problem is not in Core or Views itself. Both provide the appropriate infrastructure to completely customize the Field API rendering experience from within Views. The way that Views allows us to customize the field rendering experience is via the use of Views Plugins.

The problem with Views Datasource is that it implements Views plugins strictly via OOP inheritance. While that is perfectly O.K. if no one ever wished to override this module's behavior, it doesn't work once you need to say something like: "render me all the fields, regardless if they are empty or not", or things like "allow HTML in the title field, because that's what my manager requested". To further complicate matters, if you implement your own Views plugin, there's no clear way of telling Views Datasource: "hey, use my Views plugin!". In other words, without extensive patching or forking, there seems to be no elegant way to tame Views Datasource.

Solution

The architectural changes that I am developing aim to:

1) Provide a default algorithm for rendering fields, while allowing developers to define additional rendering algorithms and substitute our implementation with theirs. I'm considering deploying the GoF Strategy pattern for encapsulating the rendering algorithm classes. In this case the JSON plugin would provide three interchangeable rendering strategies based on the existing ones: SimpleStrategy, SimileStrategy, JqGridStrategy. Other Views Datasource will plugins will provide their rendering strategies as well. I will provide an interface to help developers define their own strategy, and a method that allows them to set their strategy as the default. The Strategy classes will be responsible for handling the rendering of Views rows.

2) Give developers the ability to override the plugin behavior. While row rendering algorithms will be encapsulated by Strategy classes, most likely I'll deploy the GoF Template Method pattern in order to provide some View-wide default behavior that can be overridden by implementers. The main difference between Template and Strategy in this case is that the Template pattern will be performing some basic operations (the "template method") that will not be possible to be overridden, while still allowing developers to define and use their own Views Datasource plugin classes, override rendering flow and modify View-wide aspects that I deem non-immutable.

3) Reduce the amount of duplicated code that currently exists between our Views plugins. This benefit will come as side-effect from "favoring composition over inheritance" when restructuring our class architecture.

4) Ease the process of adding new, or altering existing Views Datasource plugins and formats. By pooling shared behavior into composite classes, and exposing simplistic, nimble interfaces to third-party developers, we reduce the amount of code that has to be written for new plugins and formats.

Dependencies

Part of the rationalle behind this architectural change is the amount of feature requests from Views Datasource users that otherwise would not be possible. Please refer to issue #1623606: Views Datasource 2.x branch, where most of these requests are being tracked for QA purposes. Some of these requests have been marked as duplicate, meaning that they expected to be fixed automatically by the restructuring; other as postponed, meaning that they will need to be revisited on this issue is complete.

Addendum:

Why the Strategy pattern fits us?

One of the drawbacks of the Strategy pattern is that the client must be fully aware of the strategy. In our case the "client" is the Views UI, and the good news is that Views is already aware of the Strategy (rendering), because the Views UI explicitly specifies the rendering strategy [image stub]. So instead of client strategy awareness being a drawback for us, it ends fitting our use case like a glove.

The Template Method pattern implementation

At some point we must stop sub-classing Views plugin classes like if they where cloned sheep (or lab mice, for that matter). Inheritance is great when you have only one plugin, or two at must, but we have four plugins (without counting the test one). That means we have four places where code is getting duplicated, and four places where code needs to be refactored when we alter the Views Datasource API. This creates a maintenance problem and hinders improvements to an otherwise great module. A good dose of object composition will soothe these ailments.

The Template Method defines a generic abstract class that contains the code to be shared amongst Views Datasource Views plugins. Concrete Views Datasource plugin subclasses will inherit functionality that cannot be overridden, and will be forced to define subclass-specific behavior. A "concrete" method at the abstract class (probably marked as final) will provide the shared plugin functionality. Abstract methods will indicate what operations other plugins will need to implement. The brilliance of the Template Method is that it will allow us to dictate the immutable flow of the application, while allowing others to modify the parts of the flow that matters to them, mainly formatting and rendering flow.

Where is the new code?
Because of the sheer size of these changes, I will be posting my commits to my views_datasource sandbox. Currently my work is still under progress under the rvda-personal sandbox branch. Once my work is completed there I will commit my changes back to the 2.x branch of the official views datasource. This means that this issue (#1699368) will no longer be part of the #VDS-A tag, since it will not be part of the 7.x-alpha release.

Branching strategy

The following branching information applies to the views_datasource sandbox only.

• rvda - Rewrite Views Datasource Architecture branch, stores changes specific to this issue, branched from vds-a. Once major work on this branch is complete, it will be renamed to 7.x-2.x.
• vds-a - Alpha release branch, and rvda's parent. Originally rvda was going to get merged into here (as part of the 7.x-alpha release), but not anymore. This branch will be eventually removed from the sandbox.
• 7.x-1.x - Clean branch mirroring the 7.x-1.x on the original project. Originally the rvda branch was going to get merged back into 7.x-1.x, but not anymore.
• master - Currently contains a backup of my latest code, not to be synced with the real master, please ignore.