RE: Comments about sXBL

Cyril,

[Replying to Peter]
> ... so paraphrasing you, this will handle events on 
> xbl:handlerGroup, not on 
> the bound element. Am I wrong? If so, what is the difference? 

No, you're exactly right, but there is a bit more to it.

Using XML Events, you can only observe your parent element (as you have
shown) or an element that you have the @id of. Which means, unfortunately,
we have no syntax that allows us to say that we want to observe, for
example, the document object, or, in the case of sXBL, the bound node.

So, without changing the XML Events specification, the solution is to create
a sort of proxy object that you can attach your listeners to (handlerGroup)
using the usual syntax, but then come up with a cunning way to connect that
object to the bound node so that the listeners get included in the bound
node's event processing. By doing that you've moved the problem away from
the XML Events arena, and into DOM Events space.

As you can see then, to make this whole thing work, the actual DOM event
architecture itself needs to change, but as it happens, the DOM 3 Events
proposal did add a feature to allow something very, very close to this. Of
course, this does mean that DOM 3 Events needs to become a standard for sXBL
to work, but hopefully that won't be too much work ;).


> But the 
> question is: What happens if handlers are part of the 
> elements replacing 
> the 'content' element ?

They must be processed just like any other element. For example, imagine
that you have a widget for choosing colours. You have a form that includes
this widget, and all you want back is the finished colour, e.g., #CCDDEE.
This widget is actually made up of a box that shows the current colour, and
three sliders. Each slider needs to have event handlers so that as it moves
it changes the R, G or B part for which it is responsible. These events are
nothing to do with the bound node, as such, and in fact the bound node would
be completely unaware of them (especially because on a voice system a
completely different widget could be used). In this case you would declare
your handlers in relation to the sliders, and so you would have to put them
in the template.


> BTW, could you post or describe an meaningful example of 
> binding using 
> only events, no presentational part.

A simple example comes from the world of XForms. In XForms we have an
element called xf:hint that can appear in form controls:

  <xf:input ref="name">
    <xf:label>First Name:</xf:label>
    <xf:hint>Enter your first name here</xf:hint>
  </xf:input>

Now, XForms defines that an xf:hint element is actually shorthand for
showing an ephemeral message on receipt of the xforms-hint event. So, what
we actually have 'under the covers', is this:

  <xf:input ref="name">
    <xf:label>First Name:</xf:label>
    <xf:message level="ephemeral" ev:event="xforms-hint">
      Enter your first name here
    </xf:message>
  </xf:input>

But what the spec does *not* say is how an 'xforms-hint' event is
originated. This is absolutely right, because in a voice system it may arise
by someone asking for a hint or pausing for more than 30 seconds while
choosing their pizza topping on the phone, and on a visual system it may be
caused by a mouseover.

Anyway, as I'm sure you can see, all you really need to do is map the
occurrence of some platform-specific event, over to the 'xforms-hint' event,
and you now have hints for your environment. XBL is of course ideal for just
such a thing. So to round off, here is your example:

  <xbl>
    <definition match="xf:input">
      <handlerGroup>
        <xyz:dispatch
         ev:event="mouseover"
         name="xforms-hint"
        />
      </handlerGroup>
    </definition>
  </xbl>

(Note that we have no dispatch action yet, but you get the point.)

Regards,

Mark


Mark Birbeck
CEO
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
http://www.formsPlayer.com/

Received on Friday, 24 September 2004 06:20:24 UTC