Re: Repeats and events

Hi Erik,

I thought we had made it clearer than it is in the spec, but looking 
again, there is room for improvement.
This topic did come up and was discussed in detail previously, and at the 
time I believe we thought it had been made clear, but the discussion had 
gone on for some time, so maybe it was clearer when that context was 
In any case. the short answer is that we went with your option A. The 
action that is defined inside the repeat does not run because it is not 
listening to the repeat element. 
In repeat processing 9.3.3, the content of the repeat is used as a 
template for the generation of repeat objects.  The root of the repeat 
object is a group.  The action listens to that group, which behaves as a 
child of the repeat.
Aside from being "rigorous" in the definition of repeat object, we added 
the example in 9.3.3 as an attempt to further clarify how to listen for an 
event on a repeat element.  The conclusion we came to at the time was that 
you had to define the event handler outside of the repeat and set it up to 
observe the repeat (in the manner shown in the example).
I've been given an action item to propose a clarification erratum, but 
wanted to get this initial communication out in order to get any feedback 
you wanted to give.

John M. Boyer, Ph.D.
Distinguished Engineer, IBM Forms and Smarter Web Applications
IBM Canada Software Lab, Victoria

Blog RSS feed:

From:   Erik Bruchez <>
Date:   15/12/2011 09:52 AM
Subject:        Re: Repeats and events
Sent by:

Focus is a bit different: a control that is the target of xforms-focus
determines the control that receives focus without involving event

However the spec says "Setting focus to a repeat container form
control sets the focus to the repeat object associated with the repeat
index". This seems to imply that:

  <setfocus control="my-repeat"/>

dispatches to the repeat *container*. But it's not clear that this
says much about event listeners.


On Thu, Dec 15, 2011 at 9:23 AM, Leigh L Klotz Jr <> 
> What do we do for setfocus?
> On 12/12/2011 03:48 PM, Erik Bruchez wrote:
> All,
> I have a question about repeats and events, which I am not sure is
> addressed in the spec (at least not explicitly).
> In XForms 1.1, there is the concept of "repeat objects" which
> represent runtime repeat iterations. XForms1.1 states:
> "A repeat object is an implicitly generated group element that
> contains the set of run-time objects generated to represent the repeat
> template content for a single repeat item of the repeat collection.
> These run-time objects are form controls, XForms actions and other
> host language elements that correspond to elements in the repeat
> template."
> Less formally, XForms 1.1 also mentions the "repeat container"
> control, which manages the "repeat collection".
> Now, let's say we have this repeat with a nested event handler:
> <xforms:repeat ref="value" id="my-repeat">
>     <xforms:action ev:event="my-event"/>
> </xforms:repeat>
> And I dispatch, from outside the repeat, an event using the repeat id:
> <xforms:dispatch targetid="my-repeat" name="my-event"/>
> The three-pronged question is:
> 1. Does the handler run, or not?
> 2. If so, does it run once, or once per repeat iteration?
> 3. If it runs only once, in which XPath context does the action run?
> There seems to be 2 basic options:
> Option A. If you assume that the id corresponds to the repeat
> container, then it should not respond to the event, as the actual
> markup would look like:
> <xforms:repeat ref="value" id="my-repeat">
>     <xforms:group ref=".">
>         <xforms:action ev:event="my-event"/>
>     </xforms:group>
>     ...
> </xforms:repeat>
> Option B. However, if the id corresponds to the repeat iteration, then
> it should respond to the event, as if you had written:
> <xforms:repeat ref="value">
>     <xforms:group id="my-repeat" ref=".">
>         <xforms:action ev:event="my-event"/>
>     </xforms:group>
>     ...
> </xforms:repeat>
> Further, in the latter case, the event handler would run in the XPath
> context of the iteration with the current repeat index.
> There are benefits and drawbacks to each option. Option A makes sense
> once you explain to the programmer that even though he can't see it,
> there is a virtual <group> in between. However, this doesn't allow
> placing within xforms:repeat a handler that responds directly to an
> event directed to that repeat by id.
> Option B makes sense in that if you just look at the markup, it might
> be more intuitive that a handler responds to an event directed to that
> repeat by id. On the other hand, it makes making a distinction between
> events targeting a repeat iteration vs. the repeat as a whole more
> difficult.
> Is there an option C?
> -Erik

Received on Wednesday, 4 January 2012 17:09:27 UTC