This article is the second part from the series about my participation in the APEX dashboard competition. See also the other parts:

In the first part, i introduced you into the dashboard-challenge and showed how my dashboard-builder works. In this part, you will see the creation-process of the dashboard-sets. My dashboard can be found at

Dashboard-Sets: Designing the concept

So I just had implemented the look and feel of the Theme-Roller, and I thought about adapting additional features from the Theme-Roller. I took a closer look at the following features:

  • The Select-List for choosing different Styles
  • The tab for custom css
  • The buttons “Set as current” and “Save as”

Figure1: The adapted features from the Theme-Roller
In addition to these, there was another feature from APEX which inspired me to form my concept: The Theme-Roller JSON Configuration, which can be found in the shared components.
Figure2: The adapted feature from the JSON-Configuration
In the original Theme-Roller, all these parts don’t interact directly together. I mixed these things a little bit up and created the idea about the main-feature for my dashboard: The dashboard-sets, which can be shared easily between users.

Dashboard-Sets: The JSON-structure

The next step was to represent all the chosen charts as a JSON-string. I had to integrate the following properties:

  • A unique id
  • The chart-position ( since charts can be rearranged per drag and drop )
  • The chart-type ( Bar, Horizontal-bar, Line )
  • The size of the chart / it’s region ( 25%, 50%, 75%, 100% )
  • The kind of report ( e.g. the population-count per country )

In addition to that, each dashboard-set itself needed some properties as well:

  • A name ( which is also the unique identifier )
  • An author
  • The array of charts
  • A Boolean value, if the set is chosen as current dashboard-set

Every time a user creates a chart, it’s configuration is saved as a JSON-String in the current dashboard-set.
Code1: Example JSON-string with two dashboard-sets

Getting around the competition-restrictions

The generated JSON-string has another big-advantage: It can easily be saved. One of the restrictions of the dashboard-competition was the prohibition to use DDL- and DML –skripts. So I was unable to use a table for storing the saved dashboard-sets. So I came up with another idea: Storing the JSON-String in the local-storage of the browser, which is a really comfortable way to save the created dashboard-sets anyway. The local-storage feature was introduced with HTML5 and is a huge improvement to cookies. It can store up to 5 MB data per domain locally. The usage is really easy:
Code2: Using the local-storage to store the dashboard-sets
The code above shows how the reading and writing of data works. The data is stored as key-value pairs, in this case, I used the key “dashboard_json” to save the dashboard-sets.

In the last part of this series

In this part I showed you how the dashboard-sets are working together with the local-storage of your browser. In the final part of this series, you will see what kind of charting-library i was using and how the regions are generated on demand.

Jetzt teilen auf:

Jetzt kommentieren