At first, the name doesn’t tell much, but as you get to know more about what Data-Driven Content is and can do to help you achieve your reporting goals, I don’t think you will have another choice other than fall in love with it, as I did.
If you drag & drop a DDC object into a VA report and assign a few columns in the object’s Role tab, you will get a table, which is the default visualization for DDC objects. That visualization is provided for you by VA, and it uses the following URL to render the table:
When you create a new third-party visualization for the DDC object, you create an HTML file to be used as a replacement of the default URL above.
Many people tend to ignore that view, but it contains some basic, and at the same time important information about what VA is passing to the third-party visualization. In this example, the data is made of a two-dimensional table with three columns and three rows. The source data could have come from a table a lot bigger than that, but VA is querying and aggregating it using its in-memory engine and passing the results to the DDC object. So, even if you are using a third-party visualization, you are still leveraging VA’s computing power behind the scenes.
The information (or message) that VA passes to the DDC object contains the aggregated data and a few other items as a JSON structure. Every time something changes, such as a filter gets applied, or columns are added/removed/renamed, etc., a new message is sent to the DDC object. The DDC object can also be the sender of messages. For example, you may want to let VA know when the user selects something in the third-party visualization, or simply send a warning message to the user to inform that something happened. Those messages are also sent in JSON format.
This is really all that simple. In summary, there is one type of message that flows from VA to the third-party visualization (containing data, columns metadata, selections made in other VA objects that should affect the DDC object, etc.), and two types of messages that flow from the third-party visualization to VA (one to inform selections and one to send instructional messages).
Whether messages are really passed or not between the DCC object and other VA objects, it depends on two things:
Any changes made in the VA interface that affect the aggregated data (think about the default table view explained previously), such as filters, and ranks applied directly to the DCC object will trigger a new message to be sent automatically. User actions performed in the objects that are sources of actions (filter or selection in the Actions pane) defined with the DCC object will also trigger new messages to be sent. If the source is a VA object, the message is automatically sent, but if the source is the DDC object, you must handle that via code.
As a third-party visualization developer, you must add an event listener to receive messages from VA, and an event handler to properly parse and process the message to refresh the content of the visualization.
Similarly, to send messages to VA you must add code to handle events that your third-party visualization generates, such as user clicking on the visualization to select specific data points, and send a selection message to VA, or simply to send an instructional message (text) to keep the user informed about something.
Messages with selections will cause VA objects that have Actions defined with the DDC object to automatically react accordingly (be filtered or selected/brushed):
Sending instructional messages to VA will display the text inside the DDC object in the VA interface. This is good to give instructions to the report author about what type of data is required, their type, sequence, etc.:
In the second part of this article, we will dig deeper into the messages exchanged between VA and the third-party visualization, discuss a little bit of code, best practices, and examples.
Additional resources on Data-Driven Content: