- From: Peter Sorotokin <psorotok@adobe.com>
- Date: Thu, 23 Sep 2004 15:26:14 -0700
- To: Cyril Concolato <cyril.concolato@enst.fr>
- Cc: www-svg@w3.org
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