Wednesday, July 23, 2014

New tabular reports component

   As we mentioned in a previous post (Rich interactive dashboards in uberfire), the data viewer layer is not tied to just one type of visualization technology, but instead supports pluggable renderers. This means that, if so desired, each of the components of a specific dashboard can be configured with it's own specific rendering technology, independently of the renderer its fellows components might use.
On the other hand it's also possible to have only the tables report components, for example, to use a specific table rendering technology, while all the others use the default renderer (which, for now, is the Google Charts Visualization library). This is what we'll illustrate in this blog entry.

   Recently we've added a new table visualization component, which in a foreseeable near future will become the default rendering technology for table reports, replacing the previously mentioned Google library for this type of displayers.

   So, how do we tell the framework that it should visualize a table using this new renderer? Let's go back to an example from the previous post to illustrate this:

The sales pipeline dashboard.

   As you can see the 'Sales pipeline' dashboard that is shown in the above image consists of a line chart, a few pie charts, a bar chart, and finally, a table report. The latter is being visualized using the (still) default Google visualization library. Let's check out how the table report of this dashboard is setup:
The table report setup

   As you can see, this is fairly straightforward; through a sequence of API calls we tell the framework to configure a table renderer component, with its title, the default ordering column and sense, the page size, the columns it should display, and the data set it should work with.

   This setup displays the table as it can be seen in the first image, with the default google visualization library. Let's now change this to our new table component. For this to happen we need to adapt the above configuration as follows:

Set a specific renderer

   So, it's as simple as adding a call to 'renderer( <rendererID> )', to the component's setup to get the job done and that's that! The result is shown in the image below: 

New table component renderer.
   As you can see, the table report is now visualized with our new table component. It offers several improvements over the google table renderer:

  • it's based on a standard widget-set, so no dependency on third party (possibly closed-source) libraries,
  • the possibility to hide columns through a column selector pop up,
  • the ability to manually adjust the column widths,
  • the ability for the table to emit filtering events that occur within it (e.g. someone selects a specific country or product), so that other components can adapt their content accordingly (see also the entry on filtering: An introduction to displayer filtering )

Below we've included a small screen cast to illustrate some of these features:

Tuesday, July 22, 2014

An introduction to displayer filtering

   One of the most interesting features of interactive dashboards is the fact that they consist of data visualization components that can be made responsive to events that happen within some other data displayer component, which is usually being shown in the same dashboard. Equally important is that data visualization components can be told to notify to others that some kind of 'event' has happened within it, e.g. a data filter event in a pie chart, or some value that was selected inside a table report cell.

   So how is this achieved in dashbuilder?

   Check out the following example of what could be a sales dashboard:

An example sales dashboard

   We have a meter chart, a bubble chart, a line chart and a couple of bar charts in there, representing some possible sales indicators. Now imagine that a sales manager wants to check the correlation between all of these for a specific country (bubble chart), or for a specific product or employee (bar charts). If these charts were simply static visualizations, he/she wouldn't be able to do that, rendering the dashboard practically useless for detailed data interpretation.

  So, the importance of being able to configure the charts, whatever their type, and where necessary (it might not always be desirable nor useful), so that they can respond to external and / or 'self' events (i.e. filtering actions), and also be able to notify other charts of those is beyond doubt.

   As you might already know, all data visualization components in dashbuilder can be configured through a very straightforward and easy-to-use API. Take the bubble chart in the above dashboard, for instance, which is setup as follows:

The bubble chart setup

   Pay attention to the call to the 'filterOn( ... )' method, surrounded by the red rectangle, this is where all the filtering 'magic' happens. Let's dig a little deeper into what this method offers.
As you can see it accepts three boolean parameters:

  • The first one will configure the data displayer so that it will respond to the filtering events it generates itself, i.e. the event generated by the displayer will affect its own content. Say for a second we were to have this parameter to 'true' in the 'By product' bar chart configuration. If we were then to click on 'Product 11' for example, the result would be the following:


An 'auto'-filtering bar chart
   We observe that only the two bars corresponding to 'Product 11' have remained present in the 'By product' graph. It's up to the dashboard designer to determine if this effect is what is convenient for the type of dashboard and for the type of graph in its specific context. In this case we might wonder if, functionally speaking, it makes sense to have a bar chart auto-filter itself, but please note that the auto-filtering option also plays an important role in the ability to apply 'drill-down' to data displayers. However, this  will be the topic of a future post.

   Also note that when we clicked on the 'Product 11' bar, all the other graphs, with the exception of the meter chart, automatically adjusted their content to the newly set filter. This is because of the
  • Second filterOn parameter, which will configure the data displayer so that it will notify the filtering event that has occurred within it to others. Others? That is, every other displayer that has registered itself to listen to the events within a certain context (basically, although not strictly, a dashboard). This is achieved by coordinating displayers through a 'DisplayerCoordinator' component, as illustrated below:

    Coordinate displayers amongst themselves
    Every component that registers with this coordinator will be notified of the events that occur within the other components in the same coordinator instance, but only if its
  • Third filterOn() parameter, which tells a displayer to respond or not to the events that are notified throughout a specific dashboard, is set to true. For the sake of this example, this parameter was set to 'false' for the meter chart and, as you can see from the screenshot where the bar chart auto filter was demonstrated, the meter chart has not changed its content.
That's it for our brief introduction to displayer filtering, in a future post we will broaden this subject and also introduce the ability to 'drill down' in the data represented by a displayer. Stay tuned!