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

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/