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