- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Fri, 29 Jun 2018 21:29:50 +0200
- To: public-xformsusers@w3.org
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:30:16 UTC