Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

How I do self-study on a given Fiori control - part 5

JerryWang
Advisor
Advisor
‎10-24-2015 4:56 AM

Tutorial Index - how I do self study on the following topics



Content of this blog


In the previous blog, I have studied the metadata of Button control. In this blog, I will study the instance data of Button control.

I will use the public method we find in the Button control metadata, setText, as example to study how the instance data is stored and retrieved in the runtime.


I just add a new code to change the text of Button:



How does it work?




How does function setXXX() work


Set a breakpoint on line 19. In the previous blog, we have learned that all public methods which are not implemented by the control itself, but inherited from its ancestor in the prototype chain, are implemented in a generic way, as demonstrated in the example below - simply delegated to setProperty function.




Property change validation


In order to set a new property, the following two validations must be done:


1. get old property value from central property repository, this.mProperties. DON NOT mix this repository with the one in the metadata we discuss in the previous blog, as the two "this" points to different object, one to control instance itself and the other one to metadata instance. In line 29693, if the old value and new value to be set are equal, just return this to support chain operation.


2. there is a validation done in line 29691, to ensure the new value is a valid property for Text.






The validation logic again makes use of the control metadata we learnt in the past.


From metadata definition we know the data type for property "text" is "string".



A validator is returned based on the property type and its function normalize is called for validation.



Then in line 29705, the new value "Jerry" will overwrite the old value stored in central property repository, this is the whole process how a property is changed so far.


The line 29711 contains the step of model property change which will be discussed in next blog.



In line 29715, a change event "_change" is also raised.



If you would like to catch this "private" marked starting with "_" in your application, you can add pieces of code as below:



oButton1.attachEvent("_change",

  function(oEvent) {

  var oChangeDetail = oEvent.getParameters();

  debugger;

  });

oButton1.setText("Jerry");

Thus whenever there is property change, your event listener will be called with change detail.




How does function getXXX() work


Still remember the ButtonRender.js we learned in the second part of these series of blogs?


Search the keyword "getText" and set breakpoint. It is triggered in the runtime since the Renderer needs to know the text of Button so that it can render it in Fiori UI.



Again the getXXX is implemented generically just the same as setXXX.





The third parameter bSuppressInvalidate of setProperty


This part is added after I read andreas.kunz' comment:


"In line 29707 you can see the "this.invalidate()" statement. This tells the UI5 core that there is a control, which has changed its state, so the visible rendering needs to be updated. UI5 will then wait with a zero timeout for any other such changes, and then triggering a rerendering. This means the renderers of all controls, which have been changed will be called and their updated HTML will be put into the DOM, so the user sees the new values.


This invalidation can be suppressed by controls (hence the "if" around the statement, if for a certain property the DOM does not need to update of if the control wants to update the DOM directly without a complete rerendering of the entire control (this could improve performance for very large and complex controls, even though rendering is normally very fast). "


Have you ever noticed the third parameter bSuppressInvalidate of setProperty function? As its name shows, by default the control will always be invalidated if no value is assigned to this parameter when setProperty is called.



The isInvalidateSuppressed() will only return true, if the control itself is marked with true or any of its ancestor is marked true.



The comment on the two IF condition checks is very clear. For this very simple application, if you use the following code and then debug invalidate() on button control:



var oButton1 = new sap.ui.commons.Button({

    text:"Button" });

oButton1.setText("Jerry");

oButton1.placeAt("content");

The IF evaluation in line 37977 will not pass since this.bOutput is undefined and the button has no UI area.



Instead, you should use the code below, to postpone the setProperty call of Button control 2 seconds later - this time is long enough to let the button control rendered in UI:



var oButton1 = new sap.ui.commons.Button({

    text:"Button" });

oButton1.placeAt("content");

jQuery.sap.delayedCall(2000, oButton1, "setText", ["Jerry"]);

This time, you could observe the "zero timeout delayed call" mentioned by Andreas for control invalidation:




This call will finally delegate the execution to renderer function of Button renderer. Review the part 2 introduction about Button renderer if you forget it :smile:



In the next blog, I will study another important topic: How does control data binding work under the hood .

4 Comments
Labels in this area
Popular Blog Posts