Re: what should happen when a xf:insert is inside a xforms-select handler?

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 Sunday, 2 March 2008 19:02:01 UTC