{"id":122,"date":"2006-10-24T12:55:27","date_gmt":"2006-10-24T12:55:27","guid":{"rendered":"http:\/\/lachy.id.au\/log\/2006\/10\/xbl-part2"},"modified":"2006-12-14T00:02:05","modified_gmt":"2006-12-14T00:02:05","slug":"xbl-part2","status":"publish","type":"post","link":"https:\/\/lachy.id.au\/log\/2006\/10\/xbl-part2","title":{"rendered":"XBL Part 2: Event Handlers"},"content":{"rendered":"

This is part 2 in my 5 part series on XML
\n Binding Language<\/a>. If you haven\u2019t already read part
\n 1<\/a>, I suggest you do so now before you continue reading. XBL provides
\n a mechanism for attaching event listeners to elements, and declaring the
\n conditions under which the handlers should be invoked. In this article, I’m
\n going to compare traditional event handling techniques with those that will
\n be provided using by XBL.<\/p>\n

Traditional Event Handling<\/h2>\n

The following example illustrates some typical unobtrusive<\/em> scripting
\n techniques to attach event listeners, including both the window.onload<\/code> property
\n and the addEventListener()<\/code> function.<\/p>\n

window.onload = function() {\r\n    var nav = document.getElementById(\"nav\");\r\n    var li = nav.getElementsByTagName(\"li\");\r\n    for (var i = 0; i < li.length; i++) {\r\n        li[i].addEventListener(\"mouseover\", doSomething, false);\r\n    }\r\n}<\/code><\/pre>\n
Another common method, though generally considered bad practice these days,
\n  is to use the HTML onevent<\/var><\/code> attributes, like the following.<\/p>\n
<li onmouseover=\"doSomething();\">...<\/li><\/code><\/pre>\n
There are advantages and disadvantages to both methods, but the former is
\n  generally considered better because it separates the behaviour layer from the
\n  markup.  However, the latter is a simple declarative syntax that can be quite
\n  convenient in some cases.<\/p>\n
Handling Events with XBL <\/h2>\n
In XBL, instead of requiring authors to use a script to search for the elements,
\n  the event listeners are attached to those that the binding is attached to.
\n  XBL provides a simple declerative syntax which also continues to separate the
\n  behaviour layer from the semantic markup layer. Event listeners are declared
\n  using both the handlers<\/code><\/a> element and its child handler<\/code><\/a> elements.<\/p>\n
In the previous article, we looked at how bindings are associated with elements
\n  using a selector, just like in CSS.  For example, this binding will be attached
\n  to all li<\/code> elements within an element with id=\"nav\"<\/code>.<\/p>\n
<xbl xmlns=\"http:\/\/www.w3.org\/ns\/xbl\">\r\n  <binding element=\"#nav li\">\r\n    <handlers>\r\n      <handler event=\"mouseover\">\r\n        doSomething();\r\n      <\/handler>\r\n    <\/handlers>\r\n  <\/binding>\r\n<\/xbl><\/code><\/pre>\n
If present, only one<\/em> handlers<\/code> element is allowed within
\n  a binding, but it can contain as many child handler<\/code> elements as
\n  required, to capture as many different events as you like. This binding declares
\n  a single event handler that listens for the mouseover<\/code> event.
\n  When the mouseover<\/code> event is fired on a bound element (i.e. an
\n  element to which this binding is attached), the handler is invoked in effectively
\n  the same way it would have been using the other methods shown above.<\/p>\n
Event Filters<\/h3>\n
There are often times when you only want to handle an event under certain
\n  conditions.  For example, when you want to capture a click<\/code> event
\n  and do something only when the user clicks the left mouse button; or capture
\n  a keyboard event and perform different functions depending on which key was
\n  pressed.  In traditional scripting techniques, you have to check the values
\n  of certain properties using if<\/code> or switch<\/code> statements
\n  in your function, like the following.<\/p>\n
function doSomething(e) {\r\n    var code;\r\n    e = e || window.event;\r\n    code = e.keyCode || e.which;\r\n    switch(code) {\r\n        ...\r\n    }\r\n}<\/code><\/pre>\n
Much of that involves handling of browser incompatibilities, but even if all
\n  browsers supported the DOM Events standard, it\u2019s still quite complicated.
\n  XBL addresses this by providing a simple declarative syntax for describing
\n  these conditions using attributes
\n  on the handler element<\/a>.<\/p>\n
In the following example, separate handlers are provided for for handling
\n  the keypress<\/code> events depending on which character was entered.
\n  The first handles the character a<\/kbd>, the second handles b<\/kbd>.
\n  If any other character was entered, neither of these two handlers will be invoked.<\/p>\n
<handlers>\r\n  <handler event=\"keypress\" text=\"a\">\r\n    doSomethingA();\r\n  <\/handler>\r\n  <handler event=\"keypress\" text=\"b\">\r\n    doSomethingB();\r\n  <\/handler>\r\n<\/handlers><\/code><\/pre>\n
Similarly, in the following example, the handler will only be invoked when
\n  the user left clicks while holding the Shift<\/kbd> key down.<\/p>\n
<handlers>\r\n  <handler event=\"click\" button=\"0\" modifiers=\"shift\">\r\n    doSomething();\r\n  <\/handler>\r\n<\/handlers><\/code><\/pre>\n
Other Common Event Filters<\/h4>\n
There are several other filters that can be used.  The following list is a
\n  subset of the available attributes for this purpose.  I suspect these will
\n  be the most commonly used filters because they cover the majority of mouse
\n  and keyboard event usage on the web today.<\/p>\n
\n
button<\/code><\/a><\/dt>\n
A space separated list of mouse buttons pressed by the user. e.g. button=\"0 2\"<\/code>
\n      matches either the left<\/strong> or<\/em> right<\/strong> mouse
\n      buttons.<\/dd>\n
click-count<\/code><\/a><\/dt>\n
The number of times the user clicked.  e.g. click-count=\"2\"<\/code> matches double
\n      clicks<\/em>.<\/dd>\n
text<\/code><\/a><\/dt>\n
The text entered by the user.  This is different from the key code because
\n    it matches the letter that was entered, regardless of the keys that were
\n    pressed.  This is particularly important for languages that require several
\n    key presses to enter certain letters.<\/dd>\n
modifiers<\/code><\/a><\/dt>\n
Modifer keys, including alt<\/kbd>, control<\/kbd>, shift<\/kbd>, meta<\/kbd>,
\n    etc.<\/dd>\n
key<\/code><\/a><\/dt>\n
Matches against the keyIdentifier
\n      value<\/a> defined in DOM 3 Events<\/dd>\n
key-location<\/code><\/a><\/dt>\n
For matching the location of the key that was pressed on the keyboard,
\n    including standard<\/code>, left<\/code>, right<\/code> and numpad<\/code>.<\/dd>\n<\/dl>\n
In the next article in this series, I\u2019ll be taking a look at XBL Templates, which will provide significant
\n   presentaional enhancements, particularly in regards to layout.<\/p>\n","protected":false},"excerpt":{"rendered":"
A comparison of traditional event handling and event handling with XBL.<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,4,7],"tags":[],"_links":{"self":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/122"}],"collection":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/comments?post=122"}],"version-history":[{"count":0,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/posts\/122\/revisions"}],"wp:attachment":[{"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/media?parent=122"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/categories?post=122"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/lachy.id.au\/log\/wp-json\/wp\/v2\/tags?post=122"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}