W3C home > Mailing lists > Public > public-forms@w3.org > January 2012

Re: Repeats and events

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Tue, 10 Jan 2012 08:52:28 -0800
Message-ID: <CAAc0PEUhS5czArZX2VrdY2w3appAhO3AR8spv+hMcniY2vouTQ@mail.gmail.com>
To: public-forms@w3.org
John,

Thanks for the clarification. I don't think this solution is
unreasonable, in fact it's the one I am favoring as well, so feel free
to go ahead with the action item to clarify this specific point.

-Erik

On Wed, Jan 4, 2012 at 9:05 AM, John Boyer <boyerj@ca.ibm.com> wrote:
> 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 fresh.
> 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.
>
> Thanks,
> John M. Boyer, Ph.D.
> Distinguished Engineer, IBM Forms and Smarter Web Applications
> IBM Canada Software Lab, Victoria
> E-Mail: boyerj@ca.ibm.com
>
> Twitter: http://twitter.com/johnboyerphd
> Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer
> Blog RSS feed:
> http://www.ibm.com/developerworks/blogs/rss/JohnBoyer?flavor=rssdw
>
>
>
>
>
> From:        Erik Bruchez <ebruchez@orbeon.com>
> To:        public-forms@w3.org
> Date:        15/12/2011 09:52 AM
> Subject:        Re: Repeats and events
> Sent by:        ebruchez@gmail.com
> ________________________________
>
>
>
> Focus is a bit different: a control that is the target of xforms-focus
> determines the control that receives focus without involving event
> listeners.
>
> 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.
>
> -Erik
>
> On Thu, Dec 15, 2011 at 9:23 AM, Leigh L Klotz Jr <leigh.klotz@xerox.com>
> wrote:
>> 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 Tuesday, 10 January 2012 16:53:23 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 October 2013 22:06:56 UTC