Design Studio 1.3 SDK - Are script contributions for SAPUI5 method functions supported?
All of the SAPUI5 SDK component examples provided with the Design Studio Samples demonstrate how to expose property getter/setter functions as script contributions. Indeed, the SDK Developer Guide also just focuses on this. However, UI5 controls may also include method functions that allow certain actions to be performed on the control. In this context, I have the following questions:
1) Is it possible to expose method functions via script contributions in the contribution.ztl file? If yes, what is the correct syntax for doing so? Based on my experimentation so far, it seems like method functions cannot be exposed directly via script contributions;
2) If method functions are not supported for script contributions, are there any recommended approaches as a workaround? One possible approach that comes to mind is as follows:
i) Define an invisible "dummy" property of type boolean to correspond with each method function that we want to expose as a script contribution;
ii) Define invisible properties to correspond to the parameters required by the method functions;
iii) In the contributon.ztl code, perform the following tasks:
(a) Set the invisible parameter property values that correspond to the desired method function;
(b) Invoke the dummy property getter or setter function by getting or setting the boolean value of the dummy property in the contribution.ztl code;
iii). Override the corresponding dummy property getter or setter function in the component.js code with additional logic to read the invisible parameter property values and then call the method function.
Any feedback would be appreciated.
Reiner Hille-Doering replied
Hi Michael, hi Mustafa, hi Xavier,
it it is quite fascinating what you guys try and achieve with the SDK. What you are doing is effectively a simple Remote Procedure Call framework on top of Design Studio SDK's property synchronization feature. And indeed what you find out is all correct:
- Properties are updated in bulk per round trip.
- If a property was updated multiple times within a round trip (multiple assignments in ZTL), only the last survives.
- The order of property setter calls is not defined. Based on our frameworks that we use internally it might be alphabetical with some exceptions, e.g. data-bound properties at the end, followed by "metadata". But this might all change in future and differ between platforms.
- To avoid that setters are called too often, currently the corresponding getter is called before and new value is compared with old value. However, this implementation might change in the future - letting the backend decide which properties need to be send. So you shouldn't rely on the fact that new values are always really new.
- If you need to be a consistent state of your properties, you can use afterUpdate. In UI5 SDK this function is introduced with DS 1.3 SP 1 and called "afterDesignStudioUpdate".
To implement a reliable RFC, you would need a call queue, e.g. implemented by a String property containing a JSON array. As call ID I would use another int-Property that is increased by every call (instead the random number). Function args need to be serialized as JSON as well.
Maybe once one of use post a reference implementation...
BTW I'm currently implementing for 1.4 also ways to do the same trick in opposite direction: effectively calling ZTL functions from the front end. This gives a whole bunch of new possibilities for SDK components...