W3C home > Mailing lists > Public > www-svg@w3.org > September 2004

RE: Comments about sXBL

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Thu, 23 Sep 2004 14:57:48 +0100
To: "'Cyril Concolato'" <cyril.concolato@enst.fr>
Cc: <www-svg@w3.org>
Message-ID: <00ae01c4a175$4f501370$0a01a8c0@W100>


> What is the name of this feature in DOM 3 Events?


> So if I understood correctly, the handlerGroup is a place 
> holder to put 
> all the event listeners and yet-to-come dispatchers that are 
> part of the 
> interface of the binding. You put there the behavioral part of the 
> binding that will receive/emit events from/to the bound 
> element. Events 
> handling elements that deal with internal events should be put in the 
> template element. Is that right?

Well, there will be situations where the division is not so clear - it's
much like the debate about encapsulation in relation to styling.

In the example I gave it was pretty straightforward - all you want back is
the colour value, and you don't care how the widget does it. It might use
sliders, voice input, whatever. In that context you hopefully wouldn't
handle the internal events at the handlerGroup level, since you then make
your widget device-dependent.

But let's take a different example; you might have a control that allows a
user to enter an IP address, which is actually made up of four 'input'
controls. Now, you don't care about the internals of each of the 'nested'
input controls - speech, sliders, keyboard, whatever - but you *do* care
about the internals of the IP control itself. You might want to ensure that
DOMFocusOut only moves within your sub-controls, for example. So the IP
control has 'generic' processing, but each individual input control that
makes up the IP control has 'specific' processing. It might be legitimate to
implement the generic handling within the handlerGroup as a way of catching
all events from within.

In other words, just as with the styling discussion, there is no 'one size
fits all', and a lot will depend on where you want your encapsulation to
begin and end (if at all).



Mark Birbeck
x-port.net Ltd.

e: Mark.Birbeck@x-port.net
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
Received on Thursday, 23 September 2004 13:57:58 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:54:02 UTC