This is Jerry’s 80th article of 2020, and the 262nd original article of Wang Zixi’s official account.

Series directory

(0) SAP UI5 application developers understand the meaning of UI5 framework code

(1) LAZY loading mechanism of UI5 Module

(2) UI5 control rendering mechanism

(3) HTML native events VS SAP UI5 Semantic events

(4) IMPLEMENTATION details of UI5 control metadata

(5) Implementation details of INSTANCE data of UI5 control

(6) The implementation principle of UI5 control data binding

(7) Comparison of the implementation principles of three data binding modes of UI5 control: One Way, Two Way and OneTime

(8) UI5 control ID generation logic

(9) UI5 controls multiple languages (Internationalization, the Internationalization, i18n) support the implementation of the principle

(10) Button control in XML view

(11) Button control and the DOM element behind it

This article discusses event handling for SAP UI5 controls, with the differences illustrated in the following figure.

I’ll start by reviewing HTML native event handling with a simple example.

Here is a simple HTML page with an HTML native button tag at οnclick=”copyText” registering an event handler called copyText.

After clicking the button, the response function copyText copies the value of Field1 to Field2. The onclick event handler can be viewed directly in Chrome Developer Tools.

In addition to onClick, calling the browser’s native addEventListener method can also register events for DOM elements.

In enterprise web applications, DOM tree structures are often not simple. For example, an SAP UI5 application with a simple button control will automatically generate 5 div tags when the page is rendered:

If each control that needs to respond to an event registers an event handler with a DOM element using onclick or addEventListener, the performance of a Web application will deteriorate as the number of DOM event handlers increases. Therefore, SAP UI5 introduces the concept of another so-called Semantic event to do event registration and response work for UI5 controls.

Using Jerry’s article on a scaffolding application for SAP UI5 learning, without any background API dependencies mentioned in the scaffolding, develop a UI5 application containing only sap.ui.mons.button:

The Elements TAB above shows the native HTML code generated after the SAP UI5 application has been rendered. The button tag generation logic is included in the SAP UI5 framework code series 2: The renderer for UI5 controls that we introduced in the previous article.

We used the same process as the previous native HTML Button example to check the Event Listeners of the button in the UI5 app in Chrome Developer Tools, but found nothing.

When the check piece “rooted to” is selected, a number of items appear at once:

Expand click in the entry and see that SAP UI5 registers the click event on the parent node of the button tag, the DIV tag with id content, as shown in the figure below.

The sap.ui.mons.Button event registration code in UI5:

The HTML native event click is not present here, but a JavaScript object containing the property name press and the value of the JavaScript function is passed as input to the UI5 Button constructor:

When the user clicks this button, an event named click should be triggered. What does this have to do with the handler we registered here for the Press event?

The answer can be found in the UI5 button implementation source code. Switch to the Sources TAB of Chrome Developer Tools, press Ctrl + O, type Button, and select the first result, button-dgg.js:

As you can see, press is a button-supported event defined in button-dgg.js:

When UI5 button has a click event, fire a Press event (this.fiRepress ()) if it is enabled and visible:

Therefore, it is the onclick function in the Button implementation that maps event Click to event Press.

How does line 168 from the debugger above successfully call this.firePress to a UI5 program handler registered for press events?

Remember from the previous article in this series that we delved into the lazy loading mechanism of UI5 Modules in SAP?

The SAP UI5 runtime maintains a registry for all modules, storing information about them in key-value pairs. The key is of type string, and window.eval() takes loaded JavaScript files as input parameters. JavaScript object returned after execution.

Similarly, each control in SAP UI5 maintains a key-value pair event registry, mEventRegistry. The data type of the key is String, the event name is stored, and the value type is array, which stores the response function implemented by the application for this event.

The following figure shows the event registry of the Button control in my scaffolding application. It contains only one record, the key is Press, the value is an array, and the only element in it is the event response function that I implemented in the scaffolding application that contains the alert call.

The logic shown below is:

(1) THE SAP UI5 framework retrieves an array of its event handlers from the control event registry at line 237 according to the event name press;

(2) Iterate through the array and call these response functions in the for loop using the JavaScript function prototype call method to complete the event response:

This raises a new question: when was the only entry in the Button control’s event registry, mEventRegistry, populated?

Recall the SAP UI5 control prototype chain from the first article in this series:

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

This line in UI5 application:

new sap.ui.commons.Button()

The corresponding constructor for each node in the control prototype chain is executed in turn. The population of the control event registry, mEventRegistry, takes place in the constructor of the EventProvider node:

The above variable oValue is the handler for the press event passed in when I create a button instance. At line 1192, call attachPress to register the function to which oValue points. The attachPress function finally calls the attachEvent method of the EventProvider to write the key-value pair to mEventRegistry:

There is one last question left unanswered: In the Chrome developer tools shown at the beginning of this article, there are no Event Listeners on the Button tag generated after the SAP UI5 page was rendered. In its parent, the CONTENT div tag, you see the response function under the click event.

How does the click method on the div tag of a Button parent relate to the press event in the Button event registry we’ve been discussing for so long?

When the button is clicked, check the top layer of the call stack displayed in the debugger. It is found that jquery-Dgg. js of SAP UI5 responds to the HTML native click event, and the object that triggers the event is the div tag with the ID of CONTENT, not the button tag. This can be confirmed from the value of event.currenttarget.

In the above figure, the green line separates the call stack. The code below the green line handles the HTML native click event, and at the same time completes the task of Posting the click event via div to its child node, the button tag.

Button. Onclick, above the green line, maps the click event to a press event via this.firePress. All subsequent event processing in SAP UI5 is executed around this press event.

According to Andreas Kunz, head of THE SAP UI5 development team, press events like Button are called Semantic events. Unlike HTML native click events registered directly on HTML DOM elements via onclick or addEventListener, The registration and invocation of Semantic events are imposed on SAP UI5 self-implemented controls by JavaScript code of SAP UI5 framework, which is much lighter than HTML native DOM event processing and response, and can avoid application performance degradation caused by the increase of DOM tree complexity.

When Semantic events are introduced, UI5 controls don’t respond directly to HTML native events. Instead, they receive user-triggered HTML native events via an entity called UIArea and dispatch them to UI5 controls, which then map them to one-to-one Semantic events. And call the response function implemented in the application. UIArea here can be analogous to the Facade pattern in design mode, shielding application developers of SAP UI5 from the complexity of the underlying event mapping.

The detailed description of UIArea in the figure above is recorded in the OFFICIAL SAP UI5 document.

The section on UIArea highlighted below is Jerry’s article. If you are interested, you can follow this link to continue reading.

If you change the term Semantic events mentioned in this article to, say, Virtual events, it’s easy to think of the Virtual DOM introduced in Angular, Vue, and React. Essentially, these front-end frameworks introduce an intermediate abstraction layer to reduce the performance overhead of manipulating the DOM layer directly at the JavaScript layer at the cost of increasing the implementation complexity of the framework.

By the way, AngularJS controls register in the same way as SAP UI5: there is no mechanism for registering event handlers directly on HTML DOM elements.

Here is an Angularjs application. The ng-click directive in line 22 tells the Angularjs framework to sort hyperlinks by model field name when they are clicked.

How does the Angularjs framework parse the ng-click directive and complete event registration?

In the Angularjs bootstrap phase, the framework traverses the HTML DOM tree and calls the compileNodes method recursively to parse each element containing the NG directive one by one:

When parsing an A tag containing ng-click = “sortField = ‘name’ “, call the Angular element element’s on method to register the event:

If you look at the implementation code of the ON method, you can see: Angularjs does not register event response functions on DOM elements, but instead maintains a registry of control events within the framework, this.$$Listeners (SAP UI5 called mEventRegistry), using key-value data structures. To store the event name and its corresponding event response function.

Screenshot of the Angularjs stack when the event response function is called:

For more details on how SAP UI5 compares to Angularjs event handling, see my SAP community blog:

Compare Event handling mechanism: SAPUI5 and Angular

The next article in this series covers the details of UI5 control metadata implementation.

Thanks for reading.

Series directory

(0) SAP UI5 application developers understand the meaning of UI5 framework code

(1) LAZY loading mechanism of UI5 Module

(2) UI5 control rendering mechanism

(3) HTML native events VS SAP UI5 Semantic events

(4) IMPLEMENTATION details of UI5 control metadata

(5) Implementation details of INSTANCE data of UI5 control

(6) The implementation principle of UI5 control data binding

(7) Comparison of the implementation principles of three data binding modes of UI5 control: One Way, Two Way and OneTime

(8) UI5 control ID generation logic

(9) UI5 controls multiple languages (Internationalization, the Internationalization, i18n) support the implementation of the principle

(10) Button control in XML view

(11) Button control and the DOM element behind it

More of Jerry’s original articles can be found in “Wang Zixi” :