W3C home > Mailing lists > Public > public-xhtml2@w3.org > June 2008

Re: When to register events

From: <Nick_Van_den_Bleeken@inventivegroup.com>
Date: Fri, 27 Jun 2008 09:13:29 +0200
To: "Steven Pemberton" <steven.pemberton@cwi.nl>
Cc: "Forms WG" <public-forms@w3.org>,"XHTML WG" <public-xhtml2@w3.org>
Message-ID: <OF2B554835.108E84CC-ONC1257473.00559E3A-C1257475.0027AEC6@inventivegroup.com>
Hi Steven,

I (as an implementer) included my answer in-line.

> 
> Hi Forms WG, and in particular XML Events implementors,
> 
> For XML Events 2 we have had a request that we be more specific about 
when 
> listeners get registered.
> 
> We would like your advice:
> 
> 1. What should the spec say about when listeners get initially 
registered?

The spec should point out that the listeners should be attached in an 
early stage (as soon as possible I guess). In XForms for example we fire 
events when the XForms processor begins to initialize (
xforms-model-construct is sent to the models when the XForms processor is 
going to initialize itself) and document authors should be able to listen 
for those events. 
 
> 2. Should the listeners be live? In other words, if the DOM of the 
markup 
> gets changed, chould the listeners react?

We don't think that DOM mutations to the declaratively defined event 
listeners should cause changes to the run-time listener objects (the 
attached listener shouldn't be removed, change its observer, listen to 
other events, ...). If the author wants to remove/change the declaratively 
added listener he should use the script API for dealing with event 
handlers directly and not change the DOM.

If you use the declarative syntax and need conditional handlers you should 
use the if attribute instead of using script to add/remove the listener. 
Using this declarative syntax has the advantage that the conditionality is 
expressed in the document itself, what is good when you want to be able to 
save and digital sign your documents.

Furthermore it is going to be nearly impossible in some implementations to 
support listening for mutation events because the markup DOM is provided 
host language processor and not by the XForms processor (one such example 
is a current web browser, it doesn't allows you to register for mutation 
events). I know that this is just a temporary technical implementation 
issue and should not prevent you from adding the feature, but I personally 
think it isn't good practice to automatically reflect changes made to the 
declarative XML events syntax to the run-time listener objects (those 
run-time listeners could already been changed by script, and then the 
declarative syntax is out of sync with its run-time state).

> 
> Thanks for any advice you can give.
> 
> Steven
> 
> 
> 
> -- 
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
> --
> 
> 

Your e-mail was discussed by the WG and my answers therefore also reflect 
the feelings of the WG about your questions.

Regards,

Nick Van den Bleeken
Inventive Designers' Email Disclaimer:   http://www.inventivedesigners.com/email-disclaimer =
-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--
Received on Friday, 27 June 2008 07:14:13 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 23 February 2010 18:12:49 GMT