Does styling of my SAC table cause performance drawbacks?

In fact, every story designer can try out whether sophisticated styling is a performance driver of a table widget. Do the following to test whether performance issues of your table widget is caused by filthy formatting: Measure the performance of your table widget with styling and without styling and compare results. To remove all styling definitions of the table widget we can make use of table templates (figure 1) – switching the table template will prompt the story designer to eventually delete all styling definitions (figure 2) previously applied. In other words, styling will be reset after selecting a predefined template. Thereupon, we can use the refresh button at the toolbar to measure performance of the table widget without any applied styling. In case the table loads quicker without any formatting applied, this can be interpreted as a strong hint that previously applied styling definitions cause performance issues.

Figure 1: Predefined table templates

Figure 2: Reset styling by selecting a template

Speaking of templates, templates itself define look and feel of a table and can be seen as a first and very cheap (in terms of performance) styling modification – Go try them out! Below a few examples:

Figure 3: predefined styling templates

To understand how to properly style tables we inspect ad-hoc styles and styling rules in the next two sections.

Ad-hoc styles

Ad-hoc styling is a very powerful technique to style tables. To apply ad-hoc styles, select a certain region (or if desired certain cells) and apply formatting using the styling panel. Of course, this is very simple to use and provides a lot of flexibility to story designers. In the following, we show a few examples: we can easily select the whole header region and apply formatting for the whole selected area:

Figure 4: selection of a tables header region (see styling panel)

Other regions are also available, here for instance, we selected the whole column Operating Regions. Same happens here, any chosen formatting will be applied to the whole dimension Operating Regions:

Figure 5: selection of a tables dimension region (see styling panel)

In the above two examples of ad-hoc styling, SAC’s table widget saves the context of applied formatting. Hence, even if the story designer changes the drill of the table, formatting of the header region and the dimension Operating Regions won’t be discarded! Also, technically speaking: only one styling rule will be generated for each applied formatting. Note, the usage of ad-hoc styles in combination with defined selection areas is an efficient way to style tables.

There are also regions available that aren’t bound to any data context. For instance, figure 6 shows how the first column of the table is selected in the formatting panel. Of course, if we would switch dimensions in the builder panel, the formatting for the first column would remain as chosen in advance!

Figure 6: selection of a tables first column (see styling panel)

As mentioned above, ad-hoc styles provide a lot of flexibility. A story designer could even easily drag a rectangle of desired cells as a selection for formatting. In the screenshot below we selected 123 cells. Of course, we could apply formatting here, too. However, this would result in a generation of 123 styling definitions in the background. Each cell is associated to a very own context such that the system saves formatting of every marked cell in an individual styling definition. Note, styling of multiple cells via ad-hoc styling may result in performance drawbacks, because each cell will be treated as its own area and for every area a styling definition will be generated. Be selective here!

Figure 7: selection of 123 cells (see styling panel)

Styling rules:

So, how do we style multiple content in a proper way? Generally speaking, in order to format content in a efficient way, we should use as less styling definitions as possible. The concept of styling rules allows us to model complex formatting requirements and in fact one styling rule generates one styling definition in the system. Hence, styling rules are a very powerful technique to format table content in an efficient way (in terms of performance). So let’s try them out!

In this blog post we’ll keep the example simple. We would like to format one dimension (here: Operating Regions) with a particular background color:

To do that, add a new styling rule in the styling panel:

Figure 8: Addition of a styling rule (styling panel)

Afterwards, we can start configuring the styling rule. Firstly, we can define a suited name (here: Styling Rule Operating Regions). Afterwards we select Header for the dimension Operating Regions. This means we will only format the dimension members of the dimension, but not the data associated. In the member column next to the checkbox, we can see all seven members of the dimension Operating regions are selected. Now, we can define a certain style for the selection. Click Default and ‘+ Add a new Style‘.

Figure 9: Configuration of a Styling Rule

Here we can apply desired formatting. In this blog post we just change the color fill to cyan. Once done, we can click on Apply.

Figure 9: Configuration of a new Style

Now, we can see all configurations at a glance. By clicking on OK, we can see the changes in the selected table:

Figure 10: Summary of a Styling Rule

By the way, if you want to style only certain dimension members, we can easily select them in the table and the styling rule will consider the selection as the formatting context. In the screenshot below (figure 11), we selected the member EMEA and applied another style for that. By hovering over the number 1, we can see what context is applied for that particular dimension.

Figure 11: context selection of a Styling Rule

Conclusion

As a rule of thumb, we can state: use styling rules where possible to apply formatting and use ad-hoc styles in combination with defined selection areas. Apart from that, be selective with ad-hoc styles for multiple formatting regions.