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

• Part1 – UI5 Module lazy load mechanism

• Part2 – this blog

• Part3 – Html native event VS UI5 semantic event

• Part4 – Control metadata

• 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

In previous part, the following topics are discussed:

1. The module concept in UI5
2. When, where and how the button module is loaded by UI5
3. How a button instance is initialized in the runtime

In this part, I will explain how a button is rendered in Fiori UI.

Content of this blog

How is native html code for Button control generated

Use Chrome Development tool to inspect the displayed button in Fiori UI, you can find the native html source code for it.

In previous part, we identify another js file to look into, ButtonRenderer.js. Set the breakpoint on the render function, and it will be triggered and render the html native code you have found in Chrome development tool.

Below is a simple graph to demonstrate which line of js code in ButtonRenderer.js has generated which html code.

Button control and Button Renderer

Here is another question: How does UI5 framework know the ButtonRenderer.js is responsible to render the html native code of Button.js?

The metadata of Button does the trick here.

getRenderer function returns the responsible renderer name which points to ButtonRenderer.js:

And when is this this._sRendererName filled?

this.getName() returns the value stored in this._sClassName, “sap.ui.common.Button”. So the final renderer name is CALCULATED by just appending the postfix “Renderer”.

In the next blog, I will study the event handling of Button control: semantic event in Button control.