Re: Comments about sXBL

At 09:01 AM 9/23/2004 +0200, Cyril Concolato wrote:

>Hi Peter,
>
>Thank you for your answer. However, I fail to understand some points.
>
>If I write this:
><xbl:definition element="myNS:button">
>     <xbl:template>
>        <svg:handler ev:event="DOMActivate"...>...</svg:handler>
>
>you say: "This will handle events on xbl:template element, not on the 
>bound element"
>But the current proposal is to have handler in a <handlerGroup> element so 
>paraphrasing you, this will handle events on xbl:handlerGroup, not on the 
>bound element.

Yes, exactly. If event is fired on xbl:handlerGroup it will be dispatched 
to these event handlers.

>  Am I wrong? If so, what is the difference?

The difference is that xbl:handlerGroup adds extra functionality, namely 
that all events that happen on all bound elements (that are bound to that 
binding) are dispatched to xbl:handlerGroup listeners.

>  Is it just semantics associated with these elements? or maybe because I 
> don't understand what are the implications of "because XML Events works 
> purely on CoreDOM level".

XML Events spec specifies that if ev:observer is not specified, than the 
parent of that element is used. In this case the parent will be xbl:template.


>Regarding the duplication of event listeners when putting them in the 
>template, AFAIU this is an implementation issue. One could decide not to 
>clone the event listeners.

You are incorrect. Each event listener is a separate object and must be 
treated as such - even if it comes from textually identical code. This is 
true even in ECMAScript and certainly very important for languages like 
Java. Here is the code to illustrate it:

<html>
<body>
<a onclick="var self=arguments.callee; 
self.count=(self.count?self.count:0)+1; alert('Count: '+self.count);">Click</a>
<a onclick="var self=arguments.callee; 
self.count=(self.count?self.count:0)+1; alert('Count: '+self.count);">Click</a>
</body>
</html>

Each handler will count how many times it was called. If I attach such 
handler the way that you propose it will be easily detectable if there is 
one listener or many.

Furthermore, even if we could reuse listener, each element still would have 
to remember the list of its listeners, since potentially it could have a 
separate set (because of addEventListener/removeEventListener calls). It 
also would not be clear what happens on rebinding (or on listener removal 
on DOM level) - implementation would have to keep track of a lot of things. 
In our model, bound element only needs to know which binding it is bound 
to, so there is zero additional overhead.


>Regarding the fact that it would force having a template element, I agree. 
>But the reverse is true. Right now you are forced to have a handlerGroup 
>every time you have to handle events.

Yes, but handlerGroup is one per template, not one per bound element.

>  I think it is just a question of how many elements you want to define in 
> XBL. However, one benefit of having the handlers outside the template is 
> to have a clear cut between what is presentation and what is event handling.

Yes, that's an improvement over SVG's RCC where this functionality was on 
what has become xbl:definition element.

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

They work just like any regular handler elements, i.e. each instance 
registers its own listener on its Core DOM parent (or whatever ev:observer 
points to). Binding does not affect that.

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

Sure. In XBL-enabled world you'd use them all the time.

For instance if you are developing a collaboration environment you might 
develop an element that synchronizes its content with the server. Change in 
element's content would cause an event that would be processed by a handler 
and cause a change to be submitted to the server. Yet, there is no 
presentation.

Another example is loan calculator that would bind to XForms model elements 
and calculate loan parameters based on input data.

Yet another example is in HTML environments (in XBL2) where presentation 
would be adequately handled purely by CSS stylesheet (say, by specifying 
display, border and background color properties), yet element would have 
some additional logic in it, like onclick handler.

Peter



>Regards,
>
>--
>Cyril Concolato
>Dept. Comelec
>Ecole Nationale Supérieure des Télécommunications, Paris
>46, rue Barrault 75013 Paris
>Tel: +33145817991    Fax: +33145804036

Received on Thursday, 23 September 2004 22:26:38 UTC