Skip to Content

2 Comments

You must be Logged on to comment or reply to a post.

  1. Andreas Kunz

    Good blog!

    I’d just like to add some details how the browser “click” event gets to the “onclick” method in the Button control implementation:

    While it is correct that you can add event handlers to HTML tags by adding attributes like “onclick”, this is not exactly what is happening here, even though the name of the event handler in the Button is (intentionally) the same. The other way to register event handlers in HTML is using the “addEventListener” DOM function. This is what UI5 does.

    But – as you correctly noticed, this event handler is not added to the <button> tag, but to an ancestor “div tag with id “content”“. For performance reasons, UI5 does not add not many event handlers to all the HTML elements, but only to such common ancestor elements, which we call “UIAreas”. The events are centrally handled and then “dispatched” to the controls, where they originated. So the central UI5 event handler does register at this ancestor element for the “click” event (and other frequently used events) and when it happens, this central event handler checks where it comes from and checks all controls in this part of the hierarchy, whether any of them implements the “onclick” function and calls it. So this is how the “onclick” function in the Button control is called.

    Those “semantic” control events like the Button’s “press” are also meant to abstract from different platforms: on mouse devices it’s “click”, but on touch devices it’s “touchstart” plus “touchend” (or the combined “tap”). Or it could even be the “space” key when the Button is focused. But for the application it’s only important to know that the Button has been triggered. Maybe in the future you can even trigger Buttons by looking and blinking at them? Hence the Button has its own event, which internally handles all the different ways to trigger the Button.

    (0) 

Leave a Reply