- From: John Boyer <boyerj@ca.ibm.com>
- Date: Tue, 4 Mar 2008 21:36:53 -0800
- To: Aaron Reed <aaronr@us.ibm.com>
- Cc: www-forms@w3.org
- Message-ID: <OF7A2B1DEA.84326D69-ON88257403.001BE8FC-88257403.001ED886@ca.ibm.com>
Hi Aaron,
I get that the net result to a form author is that, at the time the
xforms-select occurs, the node value of the bound node may be the old
value or the new value, depending on why the xforms-select is happening.
I'm just saying that it is more of an inconvenience than an inconsistency.
The latter is a difference of behavior with no reason. The former is a
difference of behavior for a reason (the direction of travel of
information, either from UI to model or from model to UI).
So, before we go off adding context information to xforms-select (which
would not have helped in 1.0), the first question is how inconvenient?
There seem to be two cases:
1) you have an item generated by a form author
2) you have an item generated by an itemset
In both cases, you know the XPath used to make the UI binding of the
containing select or select1 form control. Let's call that the bound data
node.
In the first case, you can specifically tailor an XForms action to test
the value of bound data node relative to the specific value associated
with the hand-authored item.
In the second case, you can specifically tailor an XForms action to test
the value of the bound data node relative to the value of the item by
using the context node of the item.
Hence, it is possible in all cases to tell whether bound data node has the
same value as the selected item, should you wish to only do something if
they differ or if they are the same.
Realizing that the above may not win the convenience award, it would, for
anyone who responded to the call for expression of need, cause me to ask:
what specifically are you trying to do that you can't do?
Finally, I obviously agree with your surmise that, for the original
question you posed ("do you get one or two xforms-refresh events
when..."), but I think this issue of event order does not affect the
answer to that question.
Cheers,
John M. Boyer, Ph.D.
Senior Technical Staff Member
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
Blog RSS feed:
http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
Aaron Reed <aaronr@us.ibm.com>
Sent by: www-forms-request@w3.org
03/04/2008 03:16 PM
To
www-forms@w3.org
cc
Subject
Re: what should happen when a xf:insert is inside a xforms-select handler?
Hi John,
I think that you are viewing Erik's note of "inconsistency" being about
the event ordering.
Erik, correct me if I'm wrong, but I think the "inconsistency" that you
are pointing out has to do with the bound node value at the time a
xforms-select event handler runs. The bound node value might be the old
value (if user clicked on the item) or the bound node value might be the
new value (if the item was selected by the processor) and the form
author has no idea which it is. Whereas, if the spec separated out the
user selection from the processor item selection, then the form author
would always know the state of the bound node because the event ordering
is well defined like John states.
Now, whether there is NEED for such a separation might be an issue best
left up to our users to speak to.
--Aaron
John Boyer wrote:
>
> Hi Aaron (and Erik),
>
> Although we have been working hard on specificity, this particular issue
> is one that has been well-specified since the original Recommendation
>
>
http://www.w3.org/TR/2003/REC-xforms-20031014/slice4.html#sequence-for-select
>
>
http://www.w3.org/TR/2006/REC-xforms-20060314/slice4.html#sequence-for-select
>
>
> It has long been a bit of a thorn in the side that the select event
> happens before the value of the selection is known. Also, note that the
> event sequence is reversed when a select/select1 control is bound to a
> node that changes due to the behavior of another control or action.
>
> I believe this is what Erik called an inconsistency and asked that it be
> fixed, but I don't think it should be called an inconsistency because
> that is just ignoring the mechanics of how the processor is supposed to
> work.
>
> Consider two select1 controls, A and B, both bound to a node X. The
> user selects item I_A in control A. It is the act of selection that
> causes the xforms-select event to occur on item I_A. Although the event
> is a notification, it is a reasonable for an implementation to associate
> some default processing with this event to initiate the change of value
> for the control containing the item. Perhaps the connection is more
> subtle than adding an actual default processing handler, but the point
> is that *something* has to make the connection from selecting an item to
> exercising the UI binding of the containing control.
>
> Next, exercising the UI binding effectively does a "setvalue" action
> from the select1 control A to the model, the end result of which is an
> xforms-refresh, which dispatches xforms-value-changed events to all
> controls bound to the changed node.
>
> The prime mover is the xforms-select, which begets the actual value
> change, which begets the xforms-value-changed notification.
>
> Next, the select1 B has its value changed and the implementation (rather
> than an end-user) must select the appropriate item based on the new
> value. This is why the xforms-select on some item in control B occurs
> after the xforms-value-changed notification. Once again, it would not
> be unreasonable for an implementation to somehow associate item
> selection with default processing of the value changed event.
>
> (Part of the reason I say it isn't unreasonable is because all these
> events are not cancelable).
>
> Finally, it can be seen that the "inconsistency" is not an
> inconsistency. In the case of control A, the end-user did the selecting
> of an item. In the case of control B, the XForms processor
> implementation did the selecting. Because different mechanisms are
> doing the selecting, it is no longer reasonable to assume that the exact
> same event order would occur.
>
> John M. Boyer, Ph.D.
> Senior Technical Staff Member
> 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
> Blog RSS feed:
> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>
>
>
>
> *Aaron Reed <aaronr@us.ibm.com>*
> Sent by: www-forms-request@w3.org
>
> 03/03/2008 09:31 AM
>
>
> To
> www-forms@w3.org
> cc
>
> Subject
> Re: what should happen when a xf:insert is inside a
xforms-select handler?
>
>
>
>
>
>
>
>
>
> Thanks for pointing that out, John. I guess I must have been looking at
> the 1.0 spec, I sure don't remember seeing that nice level of detail
> when I was hunting around the spec for answers.
>
> So it looks like for the scenario I mentioned, there should be 1
> rebuild, 2 recalcs, 2 revalidates and 2 refreshes.
>
> I agree with Erik that it could be problematic for the author to not
> know the state of the bound node (whether it has already been changed or
> not) when handling xforms-select and xforms-deselect. There needs to be
> an event differentiation between when an item is selected directly by
> the user versus when it is selected because the bound node changed. Or
> make xforms-select/-deselect fire only be due to user interaction, but
> it might be too late to change it that much. Lots of people are already
> using it.
>
> Thanks for the clarification and feedback Erik and John,
> --Aaron
>
> Erik Bruchez wrote:
> >
> > I stand corrected.
> >
> > Does this really mean that we have an inconsistent behavior, as I
> > suggested?
> >
> > 1. Value changes through user interaction: a handler for
xforms-select
> > doesn't see the updated value in the instance.
> > 2. Value changes through other means: a handler for xforms-select
sees
> > the updated value in the instance.
> >
> > If so that doesn't seem right.
> >
> > -Erik
> >
> > On Mar 2, 2008, at 10:41 AM, John Boyer wrote:
> >
> >>
> >> Hi Erik and Aaron,
> >>
> >> Actually, the spec does clearly define the order of selection. The
> >> xforms-select event happens before the value is changed.
> >>
> >> Please see http://www.w3.org/TR/xforms11/#sequence-for-select
> >>
> >> Thanks,
> >> John M. Boyer, Ph.D.
> >> Senior Technical Staff Member
> >> 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
> >> Blog RSS feed:
> >> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
> >>
> >>
> >>
> >>
> >> Erik Bruchez <ebruchez@orbeon.com>
> >> Sent by: www-forms-request@w3.org
> >> 03/01/2008 11:58 AM
> >>
> >> To
> >> www-forms@w3.org
> >> cc
> >> "Forms WG (new)" <public-forms@w3.org>
> >> Subject
> >> Re: what should happen when a xf:insert is inside a xforms-select
> >> handler?
> >>
> >>
> >>
> >>
> >>
> >>
> >> Aaron,
> >>
> >> It seems to me that regarding #1, order is not defined by the spec
> >> currently. There are two cases to consider though:
> >>
> >> When the user selects an item in the UI, you could imagine either
that
> >> the control sets the value into the instance and then dispatches
> >> xforms-select / xforms-deselect, or the other way around. To me, it
> >> seem more useful to have the value set in the instance before
> >> dispatching xforms-select.
> >>
> >> What seems to argue in favor of setting the value first is that you
> >> also have the other scenario, where the item changes not in response
> >> to user interaction but to the control's value being updated during
a
> >> refresh. In that case, clearly the value in the instance is already
> >> set, and then the selection control dispatches xforms-select /
xforms-
> >> deselect.
> >>
> >> For consistency, therefore, I think that xforms-select / xforms-
> >> deselect should be dispatched after the value is set in the
instance.
> >>
> >> I don't have the absolute answer to question #2, but it is an
> >> interesting one. We should bring it up in the Working Group.
> >>
> >> But if the value is set in the instance before xforms-select is
> >> dispatched, it seems to me that you would get only one refresh.
> >>
> >> Independently from what the spec says, I have always felt that we
> >> should have the smallest amount of refreshes as possible. We had a
> >> discussion with John a long time ago about the "outer" action
handler
> >> thing. My feeling was that we should look at this not in term of
outer
> >> action handlers, but outer event dispatches. But that's probably
> >> another story.
> >>
> >> -Erik
> >>
> >> On Feb 29, 2008, at 4:24 PM, Aaron Reed wrote:
> >>
> >> >
> >> > Hi,
> >> >
> >> > One of our users found this interesting testcase that we (FF
XForms
> >> > extension) handle poorly. But as it turns out, of the processors
> >> > that I tried (Orbeon, XSmiles and formsPlayer besides ourselves),
> >> > only fP came close to handling it correctly so I don't think that
we
> >> > are the only ones unsure of how this should work.
> >> >
> >> > The problem arises if the author has a xf:select/select1 with an
> >> > item that has an event handler for xforms-select in it and inside
> >> > that event handler the author put a xf:insert. In my
interpretation
> >> > of the spec, when the user clicks on the item to select it, the
> >> > xf:insert should happen which will cause RRRR to occur immediately
> >> > after the insertion since this is an outermost action handler.
> >> > After the xforms-select fires, the bound node value should change.
> >> > Then the xforms-recalculate, xforms-revalidate, and then another
> >> > xforms-refresh will fire as per section 4.6.7 in the spec.
> >> >
> >> > fP only fires one xforms-refresh, so even though they seem to
handle
> >> > the testcase correctly otherwise, this doesn't correspond with
what
> >> > I think should happen. The other two processors only fire one
> >> > refresh but they also seemingly don't process the xf:insert so
they
> >> > probably have bugs like we do.
> >> >
> >> > So I guess I'd like to know:
> >> > 1) Should the bound node value change before xforms-select? Or is
> >> > that being left intentionally vague and being deemed
implementation
> >> > dependent?
> >> > 2) How many xforms-rebuild, -recalculate, -revalidate and -refresh
> >> > events should fire? 1 rebuild and 2 of the rest or just one of
each?
> >> >
> >> > Here is the testcase:
> >> > <?xml version="1.0" encoding="UTF-8"?>
> >> > <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1 plus MathML 2.0 plus
SVG
> >> > 1.1//EN" "http://www.w3.org/2002/04/xhtml-math-svg/xhtml-math-
> >> > svg.dtd">
> >> > <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en"
> >> > xmlns:ev="http://www.w3.org/2001/xml-events"
> >> > xmlns:xi="http://www.w3.org/2001/XInclude"
> >> > xmlns:xf="http://www.w3.org/2002/xforms">
> >> > <head>
> >> > <xf:model id="selection">
> >> > <xf:message level="modal" ev:event="xforms-refresh">
> >> > xforms-refresh
> >> > </xf:message>
> >> > <xf:instance id="choice">
> >> > <selection xmlns="">
> >> > <sort>
> >> > <item label="dummy"/>
> >> > </sort>
> >> > <types/>
> >> > </selection>
> >> > </xf:instance>
> >> > </xf:model>
> >> > </head>
> >> > <body>
> >> > <h2> Each time the testitem changes to the selected state,
> >> > it should add another node to the nodeset
> >> > </h2>
> >> > <xf:group model="selection">
> >> >
> >> > <xf:select ref="types" appearance="full">
> >> > <xf:item>
> >> > <xf:label>testitem</xf:label>
> >> > <xf:value>cool</xf:value>
> >> > <xf:action ev:event="xforms-select">
> >> > <xf:insert nodeset="../sort/item[1]"/>
> >> > <xf:message level="modal">xforms-select</xf:message>
> >> > </xf:action>
> >> > </xf:item>
> >> > </xf:select>
> >> > </xf:group><br/><br/>
> >> >
> >> > <xf:output value="count(/selection/sort/item)">
> >> > <xf:label>number of nodes: </xf:label>
> >> > </xf:output>
> >> > </body>
> >> >
> >> > </html>
> >> >
> >> > Thanks for listening,
> >> > --Aaron
> >> >
> >> >
> >> >
> >>
> >> --
> >> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> >> http://www.orbeon.com/
> >>
> >>
> >>
> >
> > --
> > Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> > http://www.orbeon.com/
> >
> >
> >
>
>
>
>
Received on Wednesday, 5 March 2008 05:37:10 UTC