Strategies of creating VisualN Drawers

Posted on: Wed, 10/25/2017 - 10:10 By: kpv

The listed below are some major approaches to creating VisualN drawers. Some of them need coding, some don't, some need just a couple of lines of code. Choose the ones that fit you and your case best. You may even find a drawer ready for you when the package registry at is ready.

Base drawers

Base drawers are the basis of the whole system. They are those very mechanisms that draw visualizations. Everything else is build around base drawers.

A base drawer is typically a Drupal plugin and a javascript script. At minimum, a drawer plugin should implement VisualNDrawerBase::prepareBuild() method to attach the js library. Once it is done, the drawer is ready to use all across the system.

Base drawers made on top of other drawers

You can see how Highcharts Bar drawer is made on top of Highcharts drawer. Technically HighchartsBar drawer class just extends Highcharts class and overriddes a couple of methods to provide a more usable configuration form, nothing more. It has nothing to do with js scripts and underlying mechanics - everything is done by the parent class. It takes 5-10 minutes to create such a drawer but in result you get a drawer with a simple configuration form which doesn't require user to know anything about highcharts.js configuration format and accomplishes one specific function - draws a Bar chart.

Of course, you may create drawers as sophisticated as you wish - it is all up to your needs and imagination. The idea is to show a pattern to create drawer hierarchies - first one drawer with a generic configuration field (e.g. for options in JSON format) and capable to use every feature of a js library is created, then other more specific drawers are created on top of it.

You will see more implementation of the approach below.

Base drawers using drawer boilerplates

There are a couple of drawer boilerplate abstract classes which reflect common approaches to create drawers. Beside of being helpful to create generic drawers in minimum time and effort they also create an opportunity to create custom drawers for users who are not drupal developers or don't have any good php skills. A major such an audience is js/front-end developers that need a way to integrate their visualization scripts into Drupal.

User-defined drawers (subdrawers)

A User-defined drawer, or subdrawer, is a configured wrapper around a base drawer with possibly some drawer modifiers attached.

Subdrawers are created via admin UI (follow to Configuration > Media > Visualization > User-defined drawers (subdrawers) in the main menu) and fully configured manually. They work transparently to the system, i.e. the systems sees these wrappers as generic drawers with all interfaces of those. This is achieved by implementing a couple of simple ideas but we won't discuss it here (see documentation for that).

Drawer modifiers allow user to modify different aspects of drawer behaviour. A typical task is to hide one field from configuration form and add another more specific one. For example in case of Highcharts drawer we may want to set initial configuration for the drawer then hide it (so that users wouldn't be able to change it or wouldn't be confused by json), and then add a textfield that would allow to set just chart title.

Base drawers with setup select (wss-drawers)

WSS-drawers are base drawers that use Drawer Setups to store their configuration. Drawer Setups are configuration entities (see VisualNSetup entity type) and have their own UI to create (follow to Configuration > Media > Visualization > Drawer setups in the main menu). The main difference between wss-drawers and other drawers is that they have a select box (or maybe a couple) which allows to select a setup for the drawer, thus when configured it basically stores a reference to the drawer setup entity instead of setup contents by itself. When a drawing is prepared, the drawer simply loads the setup and applies it. There are several benefits of such approach:

  • Setups can be reused across multiple drawers
  • Multiple drawers, using the same setup, can be reconfigured in one change
  • Possibility to use different setup bakers to create a setup (a setup baker may be thought as a form type to input setup, see documentation for more details)
  • Moving all that "technical" raw configuration out of the drawer configuration form

Base drawers and configuration metalanguages

For some js libraries that is enough to provide just one array of options to create a visualization, for others it is hardly possible. For example to draw a pie chart a library may use PieChart(options) function and for a donut chart - DonutChart(options) function respectively. In this case we need to create some kind of a wrapper script and develop a metalanguage for configuration if we want to handle the drawer behaviour using just a generic set of options.

Base drawers using a set of js libraries at once

Let's say you want to create a drawer that would be capable of drawing charts using Highcharts.js and charts using C3.js. In this case you may just add some additional setting to the drawer configuration form to distinguish one from another. It may be a radio button that will point at the library, which configuration settings are intended for.

Combined drawers

Theoretically several drawers can be taken and combined to create one drawer that would allow them to communicate in some way with one another or to influence one other's behaviour. An example could be a map with points for some kind of objects and a chart (two independent drawings). Then they are combined into one drawer to achieve the following behaviour: when a user clicks an object, the chart shows some statistics or other info for that specific object.

The approach is quite promising though not developed at the moment.

Use ready drawers

When the package registry is ready, you can search there for a drawer to solve your task instead of creating a new one. There you'll be able also to improve someone's work and to share yours.

Plans and other approaches

There is a plan to create a UI for users to register js scripts as libraries without coding and to attach them to drawers or maybe subdrawers (a question of discussion). That would allow users, especially js-developers, to create drawers without a single line of php code. Also that would make it possible to develop some kind of compatibility layer for non-drupal js visualization scripts integration.


No need to say that you can combine the approaches listed above. For example, you can move several custom scripts into one js library, create a configuration metalanguage for them and create a single drawer. Then you can use that drawer to create others on top of it or create user-defined drawers (subdrawers) based on the given one. In such a case you can make such a drawer that would provide the basis for all visualizations across the site.

There may be also edge cases when you would move several ready drawers (not just js libraries) into one drawer (and create a configuration metalanguage) that would serve as a wrapper for them and seamlessly instantiate one or another depending on the configuration and apply it to create a drawer. But you will hardly want to do something like that, it is mentioned here just for demonstration purposes.


As you can see, there are no strict limits of what and how you should do, and there is a broad set of variants and combinations at your disposal. The ones you choose depend on your cases and capabilities. Even if you are not a programmer, you can create user-defined drawers which can dramatically improve UX for your users involved in creating visualizations.

Feel free to experiment and.. keep it simple.

Add new comment

Restricted HTML

  • Allowed HTML tags: <a href hreflang> <em> <strong> <cite> <blockquote cite> <code> <ul type> <ol start type> <li> <dl> <dt> <dd> <h2 id> <h3 id> <h4 id> <h5 id> <h6 id>
  • Lines and paragraphs break automatically.
  • Web page addresses and email addresses turn into links automatically.
CAPTCHA This question is for testing whether or not you are a human visitor and to prevent automated spam submissions.