W3C home > Mailing lists > Public > www-forms@w3.org > September 2006

Feedback on 1.0/1.1: Meaning of action elements in repeated content

From: John Boyer <boyerj@ca.ibm.com>
Date: Mon, 11 Sep 2006 03:27:22 -0700
To: www-forms@w3.org, www-forms-editor@w3.org
Message-ID: <OF55A0DFAF.C7BCDD4B-ON882571E6.002F20C1-882571E6.00396FEF@ca.ibm.com>
The itemset element allows action elements in its content.   If these 
handlers use all the defaults for eventing attributes (except of course 
ev:event), then they would attach to their parent element (the itemset).

However, in the special case of itemset (and repeat), the content is 
duplicated, and one could consider there to be an implicit root element 
(an item or group) that gets wrapped around each copy of the duplicated 
content.  This would cause the actions to be duplicated into each 
generated element, and they would then attach to that implicit root 
element.

Turns out that both are useful. 

1) It would help to be able to respond to events targeted directly at 
repeat using the default way that actions are almost always written in 
XForms (using just ev:event).

NOTE: repeat doesn't currently allow actions in its content, but this is 
an error that can and should be rectified.

2) When a select or select1 choose an item generated by an itemset, it 
would help to be able to catch the select event when it appears on the 
generated item that was actually selected

NOTE:  An erratum to XForms 1.0 made itemset a target for xforms-select, 
but I do not understand why since the generated items should be receiving 
the event.  The itemset became a target because, frankly, we have been 
having difficulties with the meaning of action elements in repeated 
content, and that fix was the 'wrong' solution.

As you can see, both useful scenarios imply secondary problems that we 
need to fix.

So, the only thing that seems like it will work right now is to put an 
xforms-select handler inside an itemset to handle xforms-select events 
targeted at the itemset, which means that I can only justify actions 
within repeat attaching to the repeat by using something that I think is 
broken :-(

Finally, we really need a solution soon for how events flow between 
generated content and generating content.  I think the only near term 
solution is to say that an XML event only occurs in the *immediate* XML 
document containing the generated content, but that at when/if the event 
bubbles to the root of the generated content, then the XForms processor 
will dispatch the same event to the *parent* of the generator element.  We 
need this so that events like xforms-help that occur on generated item 
elements will percolate up to the select/select1 containing the itemset 
that generated the items.

John M. Boyer, Ph.D.
Senior Product Architect/Research Scientist
Co-Chair, W3C XForms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com  http://www.ibm.com/software/

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
Received on Monday, 11 September 2006 10:27:51 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:22:06 GMT