- From: <boyerj@ca.ibm.com>
- Date: Wed, 14 Nov 2007 09:36:08 -0600
- To: public-xhtml2@w3.org
- CC: xhtml2-issues@mn.aptest.com
This is a multipart message in MIME format.
--=_alternative 008189D988257333_=
Content-Type: text/plain; charset="US-ASCII"
We have had a lot of difficulty in XForms with using XML events due to
repeated content .
We have the most problems at the join between the repeated content and the
element doing the repeating. A simple example should help:
...
<icecream>
<desired></desired>
<flavor color="brown">chocolate</flavor>
<flavor color="pink">strawberry</flavor>
<flavor color="white">vanilla</flavor>
</icecream>
...
<select1 ref="desired">
<label>Pick one flavor:</label>
<itemset nodeset="../flavor">
<label ref="."/>
<value ref="."/>
<hint>The color will be <output ref="./@color"/></hint>
<action ev:event="xforms-select">
<!-- Do some stuff -->
</action>
</itemset>
</select1>
Note that I could have written a "help" instead of the "message" above,
but the help is the same as the above message, which more clearly shows
the connection to XML events.
The itemset keyword in XForms generates, for each node of its nodeset, a
wrapper "item" element around a label, value and message given in the
content of the itemset. The XPaths within the wrapper item are evaluated
relative to the generating node from the nodeset. So the select1 will
present a list of three items, chocolate, strawberry and vanilla. When
the user picks one, the "value" of it is placed into the node named
desired. If the user requests a hint on an item, they are told the color
of the icecream represented by that item.
We cannot do this right now in XForms because elements like hint and help
are not allowed in itemset. We could do it with a message action instead,
but the results across implementations are not likely to be interoperable.
The problem is that hint is very similar to having <message
ev:event="xforms-hint">...</message>, which has some of the same problems
as the action that listens for "xforms-select".
One problem is that it is unclear whether the action handler sets up a
listener on each wrapper item generated by the itemset, or whether it sets
up a listener on the itemset element itself, or both.
Based on having an XML events processor that is distinct from the XForms
processor, I think we get both, which is unfortunate. I think when the
document is loaded, a listener for xforms-select on the itemset is
created. Then, when the XForms processor generates each wrapper item,
that is a new XML document that contains an action handler, and so a new
listener is created to listen for an xforms-select event on each wrapper
item.
In this case, I did not intend to set the listener on the itemset but only
on the generated items. However, in this case, I think it doesn't hurt
anything to have both ***unless*** events in the generated DOM are
expected to bubble up to the generator items. I believe the two DOMs are
separate and that events don't bubble between them. I also believe that
XML Events talks about what happens within ***a*** DOM and does not define
event bubbling between DOMs. However, some have argued that just because
the spec doesn't say the events bubble doesn't mean they don't bubble.
Therefore, for the sake of clarity, please spell out the fact that the
spec does not define any bubbling behavior between two DOMs and that
events don't traverse more than one DOM unless a consumer of XML events
defines a mechanism for dispatching events in one DOM based on the
occurrence of events in another DOM. And even then, there would be a
problem because the join points between two DOMS would look like event
targets when they should really be part of the capture and bubble phase of
a multi-DOM event.
Unfortunately, while my views above about events not bubbling between DOMs
works out well for xforms-select, it does not work out so well in two
other cases.
First, sometimes you do want the events to bubble out of generated content
and into the generator.
Second, sometimes you only want the event handler to attach to the
generator (repeater) element, not to the generated elements.
For the first case, we can amend the select1 above slightly to see the
problem. Suppose you have this:
<select1 ref="desired">
<label>Pick one flavor:</label>
<hint>The color will depend on what flavor you pick.</hint>
<itemset nodeset="../flavor">
<label ref="."/>
<value ref="."/>
<action ev:event="xforms-select">
<!-- Do some stuff -->
</action>
</itemset>
</select1>
Now, we would like to be able to say that the item element is the target
of the xforms-hint event so that one can provide item-specific events. Yet
clearly the second select1 above just wants to do a round-up of all
xforms-hint events generated by all item elements and provide a more
generic hint. But for that to work, the xforms-hint targeted at the item
would also need to bubble up to the select1. We really need a fix for
this.
For the second problem, I have to turn to the xforms repeat construct, and
put a repeat within a repeat:
<repeat nodeset="some/nodes" id="X">
<action ev:event="xforms-scroll-last">
<!-- Do some stuff -->
</action>
<repeat nodeset="more/nodes" id="Y">
...
</repeat>
</repeat>
In the above example, it is clear that I want to listen for
xforms-scroll-last on repeat X. However, I contend above that another
copy of the event listener will be created to listen for
xforms-scroll-last on each wrapper group element generated by the repeat
to represent a "row" of the repeated content in a "table". However, when
an xforms-scroll-last is dispatched to an instance of repeat Y, it bubbles
up from repeat Y to the wrapper group element, where we "Do some stuff"
that was only intended to happen when repeat X received the event.
In this case I think it is a bit hacky but again an OK solution to
conclude that a listener gets created both on the repeat in the original
document and on each repeat row's wrapper group element as long as there
is an easy way to restrict the handler to only run in the former case. And
again, I realize there is *a* way, namely adding ev:targetid="X" but I
only added the IDs for the purpose of discussion and I would prefer to not
use IDs. Fortunately, this is another case that would work out nicely if
you added phase="target" AND made it the default. Then, the above markup
would look the way it acts, and it would act properly.
Cheers,
John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com
Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
--=_alternative 008189D988257333_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">We have had a lot of difficulty in XForms
with using XML events due to repeated content .</font>
<br>
<br><font size=2 face="sans-serif">We have the most problems at the join
between the repeated content and the element doing the repeating. A
simple example should help:</font>
<br>
<br><font size=2 face="Courier New">...</font>
<br><font size=2 face="Courier New"> <icecream></font>
<br><font size=2 face="Courier New"> <desired></desired></font>
<br><font size=2 face="Courier New"> <flavor color="brown">chocolate</flavor></font>
<br><font size=2 face="Courier New"> <flavor color="pink">strawberry</flavor></font>
<br><font size=2 face="Courier New"> <flavor color="white">vanilla</flavor></font>
<br><font size=2 face="Courier New"> </icecream></font>
<br><font size=2 face="Courier New">...</font>
<br><font size=2 face="Courier New"><select1 ref="desired"></font>
<br><font size=2 face="Courier New"> <label>Pick one
flavor:</label></font>
<br><font size=2 face="Courier New"> <itemset nodeset="../flavor"></font>
<br><font size=2 face="Courier New"> <label
ref="."/></font>
<br><font size=2 face="Courier New"> <value
ref="."/></font>
<br><font size=2 face="Courier New"> <hint>The
color will be <output ref="./@color"/></hint></font>
<br><font size=2 face="Courier New"> <action
ev:event="xforms-select"></font>
<br><font size=2 face="Courier New">
<!-- Do some stuff --></font>
<br><font size=2 face="Courier New"> </action>
</font>
<br><font size=2 face="Courier New"> </itemset></font>
<br><font size=2 face="Courier New"></select1></font>
<br>
<br><font size=2 face="sans-serif">Note that I could have written a "help"
instead of the "message" above, but the help is the same as the
above message, which more clearly shows the connection to XML events.</font>
<br>
<br><font size=2 face="sans-serif">The itemset keyword in XForms generates,
for each node of its nodeset, a wrapper "item" element
around a label, value and message given in the content of the itemset.
The XPaths within the wrapper item are evaluated relative to the
generating node from the nodeset. So the select1 will present a list
of three items, chocolate, strawberry and vanilla. When the user
picks one, the "value" of it is placed into the node named desired.
If the user requests a hint on an item, they are told the color of
the icecream represented by that item.</font>
<br>
<br><font size=2 face="sans-serif">We cannot do this right now in XForms
because elements like hint and help are not allowed in itemset. We
could do it with a message action instead, but the results across implementations
are not likely to be interoperable. The problem is that hint is very
similar to having <message ev:event="xforms-hint">...</message>,
which has some of the same problems as the action that listens for "xforms-select".</font>
<br>
<br><font size=2 face="sans-serif">One problem is that it is unclear whether
the action handler sets up a listener on each wrapper item generated by
the itemset, or whether it sets up a listener on the itemset element itself,
or both.</font>
<br>
<br><font size=2 face="sans-serif">Based on having an XML events processor
that is distinct from the XForms processor, I think we get both, which
is unfortunate. I think when the document is loaded, a listener for
xforms-select on the itemset is created. Then, when the XForms processor
generates each wrapper item, that is a new XML document that contains an
action handler, and so a new listener is created to listen for an xforms-select
event on each wrapper item.</font>
<br>
<br><font size=2 face="sans-serif">In this case, I did not intend to set
the listener on the itemset but only on the generated items. However,
in this case, I think it doesn't hurt anything to have both ***unless***
events in the generated DOM are expected to bubble up to the generator
items. I believe the two DOMs are separate and that events don't
bubble between them. I also believe that XML Events talks about what
happens within ***a*** DOM and does not define event bubbling between DOMs.
However, some have argued that just because the spec doesn't say
the events bubble doesn't mean they don't bubble. Therefore, for
the sake of clarity, please spell out the fact that the spec does not define
any bubbling behavior between two DOMs and that events don't traverse more
than one DOM unless a consumer of XML events defines a mechanism for dispatching
events in one DOM based on the occurrence of events in another DOM. And
even then, there would be a problem because the join points between two
DOMS would look like event targets when they should really be part of the
capture and bubble phase of a multi-DOM event. </font>
<br>
<br><font size=2 face="sans-serif">Unfortunately, while my views above
about events not bubbling between DOMs works out well for xforms-select,
it does not work out so well in two other cases.</font>
<br>
<br><font size=2 face="sans-serif">First, sometimes you do want the events
to bubble out of generated content and into the generator.</font>
<br>
<br><font size=2 face="sans-serif">Second, sometimes you only want the
event handler to attach to the generator (repeater) element, not to the
generated elements.</font>
<br>
<br><font size=2 face="sans-serif">For the first case, we can amend the
select1 above slightly to see the problem. Suppose you have this:</font>
<br>
<br><font size=2 face="Courier New"><select1 ref="desired"></font>
<br><font size=2 face="Courier New"> <label>Pick one
flavor:</label></font>
<br><font size=2 face="Courier New"> <hint>The color
will depend on what flavor you pick.</hint></font>
<br><font size=2 face="Courier New"> <itemset nodeset="../flavor"></font>
<br><font size=2 face="Courier New"> <label
ref="."/></font>
<br><font size=2 face="Courier New"> <value
ref="."/></font>
<br><font size=2 face="Courier New"> <action
ev:event="xforms-select"></font>
<br><font size=2 face="Courier New">
<!-- Do some stuff --></font>
<br><font size=2 face="Courier New"> </action>
</font>
<br><font size=2 face="Courier New"> </itemset></font>
<br><font size=2 face="Courier New"></select1></font>
<br>
<br><font size=2 face="sans-serif">Now, we would like to be able to say
that the item element is the target of the xforms-hint event so that one
can provide item-specific events. Yet clearly the second select1
above just wants to do a round-up of all xforms-hint events generated by
all item elements and provide a more generic hint. But for that to
work, the xforms-hint targeted at the item would also need to bubble up
to the select1. We really need a fix for this.</font>
<br>
<br><font size=2 face="sans-serif">For the second problem, I have to turn
to the xforms repeat construct, and put a repeat within a repeat:</font>
<br>
<br><font size=2 face="Courier New"><repeat nodeset="some/nodes"
id="X"></font>
<br><font size=2 face="Courier New"> <action ev:event="xforms-scroll-last"></font>
<br><font size=2 face="Courier New"> <!--
Do some stuff --></font>
<br><font size=2 face="Courier New"> </action></font>
<br><font size=2 face="Courier New"> <repeat nodeset="more/nodes"
id="Y"></font>
<br><font size=2 face="Courier New"> ...</font>
<br><font size=2 face="Courier New"> </repeat></font>
<br><font size=2 face="Courier New"></repeat></font>
<br>
<br><font size=2 face="sans-serif">In the above example, it is clear that
I want to listen for xforms-scroll-last on repeat X. However, I contend
above that another copy of the event listener will be created to listen
for xforms-scroll-last on each wrapper group element generated by the repeat
to represent a "row" of the repeated content in a "table".
However, when an xforms-scroll-last is dispatched to an instance
of repeat Y, it bubbles up from repeat Y to the wrapper group element,
where we "Do some stuff" that was only intended to happen when
repeat X received the event.</font>
<br>
<br><font size=2 face="sans-serif">In this case I think it is a bit hacky
but again an OK solution to conclude that a listener gets created both
on the repeat in the original document and on each repeat row's wrapper
group element as long as there is an easy way to restrict the handler to
only run in the former case. And again, I realize there is *a* way,
namely adding ev:targetid="X" but I only added the IDs for the
purpose of discussion and I would prefer to not use IDs. Fortunately,
this is another case that would work out nicely if you added phase="target"
AND made it the default. Then, the above markup would look the way
it acts, and it would act properly.</font>
<br>
<br><font size=2 face="sans-serif">Cheers,</font>
<br><font size=2 face="sans-serif">John M. Boyer, Ph.D.<br>
STSM: Lotus Forms Architect and Researcher<br>
Chair, W3C Forms Working Group<br>
Workplace, Portal and Collaboration Software<br>
IBM Victoria Software Lab<br>
E-Mail: boyerj@ca.ibm.com <br>
<br>
Blog: </font><a href=http://www.ibm.com/developerworks/blogs/page/JohnBoyer><font size=2 face="sans-serif">http://www.ibm.com/developerworks/blogs/page/JohnBoyer</font></a><font size=2 face="sans-serif"><br>
<br>
</font>
--=_alternative 008189D988257333_=--
Received on Wednesday, 14 November 2007 15:39:20 UTC