- 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 UTC