A widget contains at least two and possible three files:
1.The metadata file, which SAC uses to define the widget
2.A JavaScript file with the code for rendering the widget in the canvas of the application or story. This will be written as a web component. This is the "main" web component.
3.An optional JavaScript file with the code for rendering a web component in the styling pane of the widget during design time. This is the "styling" web component. Source: SAP
A property needs two things.
It needs to be defined in the properties section of the metadata .json file and it needs to have getters and setters in the web component .js file. The property definition in the metadata will actually make the property available for reading or setting via script. The getters and setters are what actually hooks that property into the widget.
Suppose we had a property called foo: The metadata property definition would have three attributes. It would have the type of property, such as string or number. It would have a default value and it would have a description, for the designer. In the web component .js file, we'd need to add two methods. get foo() set foo()
The get foo() function would be fired whenever we asked for the value of foo via script. The value of foo is whatever we return from this function. It could simply return and existing variable from the web component, it could perform a complex computation, etc. It can do whatever you want, as long as it returns something of the expected type.
The set foo() function would be fired whenever we set it via script. Again, you can do anything you want on this function, but you don't need to return anything as a return is not expected for a setter. Source: SAP
Methods
The methods section of the metadata is how you add script methods. Each method has a name, a list of parameters that is called with, and a body. The name is what the designer will call via script. The parameters are the values passed in. Each parameter definition includes a name, a type and a description. The body is the script that is run when the method is called. It is important to note that this is a script, meaning that it does not have access to the internal workings of the web component, but can see the Analytics Designer scripting API. Be careful here to only execute scripts involving the current widget (via the keyword this) or objects that you can always expect in the app. Source: SAP
Events
SAP Analytics Cloud widgets have two separate kinds of events; events within the widget itself and ones dispatched to the scripting environment.
Both are running in the JavaScript engine of the browser, but are segregated and you should not confuse them. 1.Traditional JavaScript eventing is listening for browser events; such as onClick. The Mozilla developers page has an excellent and comprehensive reference of browser events.
2.The ones that you define within the metadata and these give you the hooks to react via script. You add events to the metadata. Each of these events is a script hook. You can name them whatever you want and add as many of these script hooks as you want. You use the dispatch Event method built into the web component class to fire off these named events. These custom events could be for anything. E.g. you can fire an event whenever a property changes, whenever the user mouses over the widget, etc. You could even add an event for screen resize and provide a scripting hook for that. Source: SAP
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
5 | |
5 | |
5 | |
4 | |
4 | |
3 | |
3 | |
3 | |
3 |