Re: 12.2.1 References to Elements within a repeat Element

But, by the way, I think we still have to make clear that @targetid on  
<dispatch/> is only resolved when the event is actually dispatched (i.e.  
after it is taken from the queue).

Steven


On Fri, 29 Jun 2018 21:29:50 +0200, Steven Pemberton  
<steven.pemberton@cwi.nl> wrote:

> On Fri, 29 Jun 2018 11:12:06 +0200, Nick Van den Bleeken  
> <Nick.Van.den.Bleeken@inventivegroup.com> wrote:
>
>> 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, ...
>
> Right.
>
> So what we can say is:
>
> "Within the set of runtime objects containing the source object, if the  
> target element is further nested in repeats the target object is  
> identified by the current values of the repeat indexes of those repeats;  
> if any index is zero, no  object is identified. If the target element is  
> not nested in repeats, the single target object is identified."
>
> And then a couple of examples.
>
> Steven
> (Thanks for your help with this)
>
>>
>> Best,
>>
>> Nick
>>
>> 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).
>>    Steven
>>    >
>>     > 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 19:40:52 UTC