Introduction
Design Studio 1.4 has introduced a very powerful new feature in the SDK that allows events to be bound to script methods, as described in the What's Coming in Design Studio 1.4 SDK blog post by Reiner Hille-Doering, with further examples in Design Studio SDK: Examples for Binding Events to ZTL Scripts by Karol Kalisz. The significance of this feature is that it has the potential to allow the development of components that require very little or no scripting on the part of the application designer, a key issue raised in Topic 2 of this blog series with respect to the need for less coding in Design Studio to encourage adoption across a wider audience.
While this new feature is a great step forward in enhancing innovation opportunities with the SDK, it currently comes with a major limitation (in my opinion) of not being accessible from the Advanced Properties Sheet, thereby restricting the full potential of innovation that could otherwise be achieved. The intention of this edition of the Design Studio Innovation Series is to emphasise the need and highlight the use cases for accessing script APIs from the Advanced Properties Sheet.
Background
In brief, the new event binding feature allows a reference to a private ZTL script contribution method to be pre-defined as the default script for an event. This method can then be invoked by triggering the event that it is bound to from within the component code. The ZTL method can call any API method to cause an interaction, get information or set properties, thereby allowing more dynamic SDK components to be developed. However, there are situations where it would be advantageous to also have access to the script API from the Advanced Properties Sheet, which I'll now provide examples of.
Use Cases for Script API Calls from the Advanced Properties Sheet
The main advantage of script API access from an Advanced Properties Sheet is to improve the application designer experience by allowing full configuration of an SDK component at design-time, without the need for the application designer to manually code script or lookup technical names of dimensions.
The examples below are related to data sources and demonstrate why script API access is necessary because the information required for these use cases is not available from the Data Runtime JSON or Metadata Runtime JSON provided by the SDK framework. Of course I expect there may also be non-data source related use cases as well.
1) Selection of Dimensions not included in the Initial View of a Data Source
At design-time, the initial view of a data source is usually defined to return a result set which is a subset of what is available in the data source. A common requirement is to subsequently be able to swap dimensions in and out or filter based on different dimensions at run-time. An example initial view screenshot in this context is shown below:
Here, the initial view is defined with only one dimension, Airline ID but there are additional dimensions available as highlighted in the left panel above. However, in the Advanced Properties Sheet it may be desirable to list all of the available dimensions (via the getDimensions() script API method) so that the application designer can select and configure which of these dimensions should be made available to the end user at run-time for the purposes of swapping or filtering dimensions.
2) Selection of Measures not included in the Initial View of a Data Source
Another common requirement is to be able to swap measures in and out. An example initial view screenshot in this context is shown below:
Here, only five of the available measures are defined in the initial view. In the Advanced Properties Sheet it may be desirable to list all possible measures (via the getMeasuresDimension() and getMembers() script API methods) to allow the application designer to (for instance) select which sets of measures can be swapped and configure interactions associated with them, to be made available to the end user at run-time.
3) Selection of Variables in a Data Source
When variables are defined for a data source, it may be desirable to allow the application designer to select these from a list (via the getVariables() script API method) in the Advanced Properties Sheet for the purposes of configuring dynamic calculation of values at initialisation or definition of a custom variable input form.
Implementation
Normally, I would have expected to be able to implement the above scenarios by calling the callRuntimeHandler function from the Advanced Properties Sheet to execute a function in the Component JavaScript file that triggers the event bound to the ZTL method. However, it turns out that raising events at design-time is not supported, so the new Event Bound Script Methods feature is not available to the Advanced Properties Sheet. There may well be technical reasons why raising events at design-time is not feasible. If that's the case, all I am suggesting is that an alternative approach/feature is developed for accessing script API methods via the Advanced Properties Sheet.
Conclusion
Hopefully I've made a good case for why there's a legitimate need to enhance the Event Bound Script Methods feature introduced in Design Studio 1.4, so that it is also available from the Advanced Properties Sheet. I think this would allow the development of SDK components with significantly improved usability both from the perspective of the application designer and end user.
I have also raised this in the Design Studio Idea Place for those of you that may wish to vote and express your support if you think the enhancement would be of benefit: Idea - Allow Script API Calls from the Advanced Properties Sheet of an SDK Component
Comments and suggestions are welcome and encouraged.
Blog Series Index: Design Studio Innovation Series - Welcome