JSON Object - Design Studio 1.6 - M Mode/Commons Mode - Inclusion of component causes infochart component to not display category axis labels

[PtrckGdwn]

Hi All

This is a bit of a weird one (to me at least).

I am using the JSON Object technical component - it is awesome. However, I have noticed one problem which is a bit of a deal breaker:

In M mode, inclusion of the JSON object component causes Info Chart components to stop displaying category axis labels. It appears that the svg groups for the category axis is there, there are simply no text elements in the svg.

Steps to reproduce:

• Create a blank M mode application
• Add a datasource (DS_1). Doesn't need to be anything special, just one dimension and one measure will do. I am using a UNX and do not have either BW or HANA.
• Edit the initial view so that the dimension is in rows, and measures in columns.
• Add an Infochart component (INFOCHART_1).
• Set DS_1 as the datasource for INFOCHART_1.
• Set the chart data selection to include the measure.
• The chart will probably default to a column chart. Leave it as is (the issue will affect any chart type).
• Run the application (locally will do). The chart should have category labels displayed.
• Add a JSON Object to the application (JSONOBJECT_1).
• Run the application (locally will do). The chart will not have category labels displayed (although there is space for them). You can inspect the HTML/SVG - there are no text elements within the axis label group).
• Remove the JSON Object from the application.
• Run the application. Chart is back to normal.

I have not tested this in Commons mode. The issue does not seem to affect Component Manager, Array, Collection components, but others I have not checked may be affected. I am using the latest version of the components.

Are you able to investigate and fix? The JSON Object is incredibly useful and I really want to use it but cant with this issue.

Update: This issue also affects the Infochart when running in commons mode.

[MartinPankraz]

Hi Patrick,

I was following your description but I can't reproduce. I see the chart with x- and y-axis labels in all cases.

I am running DS16 SP1. It seems your problems source is something else. Anything else you can share with us to check your problem?

Kind regards
Martin

[KarolKalisz]

Hi,

please take the current version, I have found the issue (was reported to be by email I have created #96.

Karol

[MartinPankraz]

So I checked Karols fix then :-D

[PtrckGdwn]

Thanks Karol and Martin.

I have a question regarding the JSON object component and performance.

I have a fairly complex app that I am working on. Essentially it is a KPI dashboard, with functionality to explore KPIs through a variety of charts. These charts are pre-configured to show the most relevant configuration for the KPI being explored. For example, charts will display the most appropriate chart type and measures. The user can then alter/interact with the chart by switching between appropriate chart types and measures for the chart. I am using an info chart and altering it through script (using a controller function).

You might ask; why not using the infochart feeding panel and the chart picker? The answer is that the audience for this dashboard will not be willing to use such controls and will almost always only look at the "default" configuration I set. Also, using such controls with my data model allows the user to construct a chart which is completely misleading.

So, to cater for this I am setting up configurations for charts which allow me to control the navigation/chart settings/compatible chart types/measures without hard coding the entire thing. This leads me to the performance question. I am tossing up between the three following methods:

1. Store JSON strings in global script variables. Use a single JSON object component. Create and navigate objects to retrieve information each time a script requires the information. Obviously this means I will be clearing/creating JSON objects (from global script variables) quite often. I imagine there is a fair bit of overhead in creating the objects (a couple of them are quite complex and involve nested objects and arrays), and also in traversing the object to retrieve the information required (which also requires creation of another JSON object in the case of nested JSON). The plus side is the number of components in the application is reduced and there is (in my mind at least) good separation between data/configuration and configuration objects. This was the method I was using before I discovered the bug wrt infocharts.

2. Same as above, but rather than clearing/clearing as required, add three JSON object components to the application and during start up initialise them based on the global script variables (i.e. they are created once only). I would then retrieve information from these objects as required. I would also need a "utility" JSON component to do this (to hold temporary objects due to nesting). I imagine this would save a bit of overhead with respect to object creation, but it comes at the cost of more components. I am also thinking that it may also increase overall memory consumption as not only do I keep the objects "live", I will still need to traverse them and create temporary objects to retrieve information.

3. Do not use JSON components at all. "Store" the configuration information in arrays of string arrays. Since global script variables cannot be arrays these arrays must be hard coded in script functions (something I am not a fan of - in my mind configuration data should be separated from application script), which also include code to retrieve information from the arrays as required. I am not sure if the arrays are instantiated each time the function is called, but if they are this could add quite a bit of overhead (the arrays can be quite big). It also requires quite a bit of looping to get the information required. I have implemented this method after discovering the bug and it works.

Do you have any thoughts about which would be the best way to go? It might be you have an idea that I have not considered.

Cheers, Pat

[MartinPankraz]

Hi Patrick,

I can see what you are trying to achieve. I have got some thoughts for you to consider.

• How about hiding the feeding panel and the chart type picker so that only users who want to use it can display it? Buttons with arrows are often used for that. You can check out the ready-to-run dashboards on the designstudio templates to get some ideas.
• I would advise to get some proof for your assumptions regarding memory usage and loading overhead. You could use the url parameter PROFILING=X for that when running your dashboard and especially load intensive use cases. Given that data you should be able to decide which approach fits your needs best.

In general I haven't seen any recommendations regarding number of components vs. DesignStudio scripting. From my experience I would think that the compiled code for the DesignStudio scripting is better in performance than a bunch of interpreted JavaScript files.

Let us know what your research brought up. I would be interested to see what you came up with.

Regards
Martin