- From: Steven Pemberton <steven.pemberton@cwi.nl>
- Date: Fri, 29 Jun 2018 21:38:36 +0200
- To: public-xformsusers@w3.org, "Nick Van den Bleeken" <Nick.Van.den.Bleeken@inventivegroup.com>
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:39:03 UTC