W3C home > Mailing lists > Public > public-xformsusers@w3.org > June 2018

Re: 12.2.1 References to Elements within a repeat Element

From: Nick Van den Bleeken <Nick.Van.den.Bleeken@inventivegroup.com>
Date: Fri, 29 Jun 2018 09:12:06 +0000
To: Steven Pemberton <steven.pemberton@cwi.nl>, "public-xformsusers@w3.org" <public-xformsusers@w3.org>
Message-ID: <F16672BC-74EF-4B07-A260-D0729A775F43@inventivegroup.com>
Hi Steven,

I totally agree that the current text is long and convoluted.

I'm not sure if the 'problem' with the new IDREF resolution text only occurs with delayed dispatching of events. I think it for example also happens when an event is dispatched and handled inside of a repeat iteration which is not the 'current' repeat iteration (its index is not equal to the current index of the repeat). The xforms-value-changed event for example can be dispatched to controls not having the focus, and consequently it could not be in the 'current' repeat iteration. Other examples are handlers for the MIP related notification events, custom events, ...



´╗┐On 29/06/2018, 11:02, "Steven Pemberton" <steven.pemberton@cwi.nl> wrote:

    On Thu, 28 Jun 2018 15:32:42 +0200, Nick Van den Bleeken  
    <Nick.Van.den.Bleeken@inventivegroup.com> wrote:
    > Hi Steven,
    Hey Nick! Great to hear from you, and glad you're still reading the list.
    > Isn't there a difference between your text and the original text? In the  
    > original text the IDREF is resolved relative to the current 'runtime'  
    > iteration of the repeat the element resides in for repeats that are in  
    > common AND the current repeat index (for example set with  
    > setindex-action. In your text only the current repeat-index is used.
    > I can only think of one use-case where the current repeat index is  
    > different from the current 'runtime' iteration of the repeat, and that  
    > is if you have a delay on a dispatch action.
    > Example:
    > <xf:repeat ref="entry" id="outer">
    >     <xf:repeat ref="sub-entry" id="inner">
    > 	<xf:input ref="field1" id="i-1">...</input>
    > 	<xf:setvalue ref="field1" value="'foo'" ev:event="my-custom-event"  
    > id="c-1"/>
    > 	<xf:trigger>
    >                   <xf:dispatch ev:event="DOMActivate" name="  
    > my-custom-event " targetid="c-1" delay="5000"/>
    > 	</xf:trigger>
    >     </xf:repeat>
    > </xf:repeat>
    > When you have multiple entries and or sub-entries AND after you activate  
    > the trigger you give focuds to an input field of a different iteration,  
    > the value of the incorrect repeat iteration will be set.
    OK, well that sounds like we need to tweak the definition of <dispatch/>  
    with a delay. But that would then fix it surely?
    The current text is long and convoluted (and I'm not convinced it covers  
    everything, partly because of its length).
    > I know that it is a contrived example, but I guess you can have this  
    > scenario also in real-life use cases. But my XForms knowledge is getting  
    > a bit rusty...
    > Best,
    > Nick
    > On 28/06/2018, 14:05, "Steven Pemberton" <steven.pemberton@cwi.nl>  
    > wrote:
    >    https://www.w3.org/community/xformsusers/wiki/XForms_2.0#References_to_Elements_within_a_repeat_Element

    >    I was trying to simplify the language in this section to try and make  
    > it
    >     easier to read, and I can't find any case that isn't covered by the  
    > text:
    >    "The target object is identified by the current values of the repeat
    >     indexes of the enclosing repeats. If any index is zero, no object is
    >     identified."
    >    Am I missing anything?
    >    Steven

Received on Friday, 29 June 2018 09:12:40 UTC

This archive was generated by hypermail 2.3.1 : Friday, 29 June 2018 09:12:41 UTC