In previous part, it is explained how the native html code of Button control is generated by its renderer, ButtonRenderer.js.

"click" event VS "press" event

As we can find in Chrome network tab, the UI5 Button control is represented by native "button" tag. In this part, I will share how I study the event handling logic of this control.

In W3School, we are taught that the event for mouse click on button tag is "onclick". Quite clear, isn't it?

Go back to our simple application, you will surprisingly find that no event listener is registered on this button element.

Instead when you click the checkbox "Ancestors", this time, a event handler for click event, is found to register on its parent node, the div tag with id "content".

Also in our sample application, we don't register the handler function on "click" event. Instead we simply pass one object to the Button constructor, which contains one field "press" pointing to a function.

So when user clicks button in the browser, how can UI5 framework know the function we register to the "press" must be called to react on the native "click" event? What is the relationship between "press" and "click"?

The "press" event is defined as one part of metadata in Button.js.

Search the keyword "press" in this file, and one hit is Button.prototype.onclick. To verify whether it is this function which finishs the "translation" from "click" to "press", we set a breakpoint on it.

In the runtime, when the button is clicked, Button.onClick is called with one JQuery event object of type "click".  It is this onclick function being responsible to delegate the native click event to UI5 event "press".

"Press" event registration

How does this.firePress finally succeed to call the function "console.log('Alert from ' + oButton1.getText());" we defined in our sample application?

Debug into the firePress implementation, it simply queries the event handler for press event from a central array, "this.mEventRegistry".

In our simple application, we never do any explicit event registration, so when and where our event handling is filled into that central event repository array "this.mEventRegistry"?

Still remember the prototype chain described in part 1 ?

BaseObject -> EventProvider -> ManagedObject -> Element -> Control.

The mystery is in EventProvider's constructor:

In the first chapter of this blog, we find the event handler of the button tag's parent, the div tag. Click the hyperlink below:

Set the breakpoint there and click the button again. Through callstack you can understand how the mouse click event has been passed from parent div tag to the children button tag:

Summary

The "press" event in this blog is described  by SAPUI5 as "semantic events". Semantic events do not exist as native HTML browser events. The UI control implementation is responsible for mapping native browser events to semantic events. For more details please refer to SAP help: UI Control API: Event Handling.

In the next blog, I will study the metadata of the Button control.