- Tutorial Index - how I do self study on the following topics
- Part1 - UI5 Module lazy load mechanism
- Part2 - Control renderer
- Part3 - Html native event VS UI5 semantic event
- Part4 - this blog
- Part5 - Control instance data - how are function setXXX() and getXXX() implemented
- Part6 - Control data binding under the hood
- Part7 - Implementations for different binding mode: OneWay, TwoWay, OneTime
- Part8 - Control ID
- Part9 - Control internationalization support
- Part10 - Button control in XML view
- Part11 - Button control and its underlying DOM
- Content of this blog
- How can I get control data in the runtime
- aAllPublicMethods
- aPublicMethods
- mAllAggregations
- mProperties
- oParent
Tutorial Index - how I do self study on the following topics
Part1 - UI5 Module lazy load mechanism
Part2 - Control renderer
Part3 - Html native event VS UI5 semantic event
Part4 - this blog
Part5 - Control instance data - how are function setXXX() and getXXX() implemented
Part6 - Control data binding under the hood
Part7 - Implementations for different binding mode: OneWay, TwoWay, OneTime
Part8 - Control ID
Part9 - Control internationalization support
Part10 - Button control in XML view
Part11 - Button control and its underlying DOM
Content of this blog
In the second part of this tutorial, we figure out that the responsible Render name is stored in Button control's metadata:
In this part, we will concentrate on the Button metadata.
How can I get control data in the runtime
Since we already have the button control instance returned by new keyword, simply call its function getMetadata() and that's it.
You can find there are lots of useful information stored in the metadata. I will go through the most important fields one by one.
aAllPublicMethods
When you type "oButton1." in Console, you find lots of methods available in the list. Where do them come from? From the control metadata, stored in this array aAllPublicMethods.
From this array, we find there are totally 110 public methods. However if you check the source code Button.js, you can not find most of those methods defined there. The prototype chain works here again. Most of the methods are defined not in Button.js itself, but in the Button control's ancestor node in the prototype chain.
if you type the code below in console, you will get result: false.
oButton1.hasOwnProperty("getText");
The public methods of a given control is an union of its own public methods defined in its JS file and the public methods belonging to all its ancestors in the prototype chain:
aPublicMethods
A subset of aAllPublicMethods, defined in the metadata.publicMethods area. See one example below for EventProvider:
In the runtime, they are parsed as below:
mAllAggregations
List all available Aggregation. One example is tooltip. It gives hint that the button tooltip is stored as an aggregation, and its value could be queried out via the sGetter: getTooltip:
That's the reason we type the following code in console and we can get the tooltip as expected.
mProperties
List all the properties together with their Getter and Setter. Keep in mind this is the metadata, so you can not expert that the text we specified in the JS code "Button" could be found here. The "mProperties" here just stores the metadata of properties, not the instance data.
oParent
Points to its ancestor's metadata.
There are two ways to get the total number of all public methods of Button control: 110.
approach1: its direct parent's all public methods + its public method.
For button control, it is 75 + 35 = 110.
approach2: accumulate public methods number of each node in the prototype chain.
Keep in mind this prototype chain as always:
BaseObject -> EventProvider -> ManagedObject -> Element -> Control
In the next blog, I will study the instance data of Button control. I will use the setText and getText as example for research.
- SAP Managed Tags:
