Skip to Content

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

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:

/wp-content/uploads/2015/10/clipboard1_816960.png

How does it work?

/wp-content/uploads/2015/10/clipboard2_816961.png

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.

/wp-content/uploads/2015/10/clipboard3_816962.png

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.

/wp-content/uploads/2015/10/clipboard4_816963.png

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”.

/wp-content/uploads/2015/10/clipboard5_816964.png

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

/wp-content/uploads/2015/10/clipboard6_816965.png

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.

/wp-content/uploads/2015/10/clipboard7_816966.png

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

/wp-content/uploads/2015/10/clipboard8_816967.png

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.

/wp-content/uploads/2015/10/clipboard9_816968.png

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.

/wp-content/uploads/2015/10/clipboard11_816969.png

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

/wp-content/uploads/2015/10/clipboard12_816970.png

/wp-content/uploads/2015/10/clipboard13_816971.png

The third parameter bSuppressInvalidate of setProperty

This part is added after I read Andreas‘ 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.

/wp-content/uploads/2015/10/clipboardp1_821307.png

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

/wp-content/uploads/2015/10/clipboardp2_821308.png

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.

/wp-content/uploads/2015/10/clipboardp3_821369.png

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:

/wp-content/uploads/2015/10/clipboardp4_821370.png

/wp-content/uploads/2015/10/clipboardp5_821371.png

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 🙂

/wp-content/uploads/2015/10/clipboardp6_821372.png

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

4 Comments
You must be Logged on to comment or reply to a post.
  • Good description of what’s happening!

    One detail which could also be mentioned to understand how UI5 rendering happens:

    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).

    • Hi Andreas,

      Thanks a lot for your comment. When I debug into the invalidate function as you mentioned, I have learned some new stuff. I have appended them into this blog. Thanks for your suggestion 🙂

      Best regards,

      Jerry