W3C home > Mailing lists > Public > public-forms@w3.org > August 2008

Re: Question about 9.3.3 Repeat Processing note

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Wed, 20 Aug 2008 14:07:09 -0700
Message-Id: <1ACDE609-C422-4FD3-AA9F-9281FAEC917E@orbeon.com>
To: "public-forms (new)" <public-forms@w3.org>

John,

> First, please note that the language changed slightly in the  
> editor's draft due to prior analysis.  Apparently, there is no such  
> thing as reaching the target in the capture phase, so the words have  
> been amended to reflect that fact.

> Second, we did once upon a time have long discussions about the  
> insert action behavior, and concluded that the insert action would  
> *do* the insertion and then, after the insertion was completed, it  
> would dispatch xforms-insert as a notification that the action had  
> taken place.  So, it was intentional that the behavior of insert was  
> not assigned to be the default action of the event.
>
> The language about repeat index is there because we don't want there  
> to be a tight coupling between the module that offers the insert  
> action and the module that offers repeat.

There is a slight misunderstanding: all of the above is good. I think  
updating indexes and repeat iterations should be decoupled and  
processed separately, and this is quite well done in XForms 1.1.

My comments regarded the wording ("in response to") and trying to  
figure out what was the intention of the text regarding when repeat  
iterations should be created/deleted.

> Is there a reason to revisit the status of xforms-insert/xforms- 
> delete as notification events (for XForms 1.2 or later)?

If "notification" means "there is no default action after completion  
of the bubbling phase", then they are still notification events. If  
"notification" means "there is no standard action taking place at any  
time during processing of the event", then maybe that status should be  
revised.

-Erik

>
> All,
>
> About this text in 9.3.3:
>
> "The repeat item generation and repeat index update on insertion must
> behave as if it occurs in response to the xforms-insert event
> dispatched by the insert action. The index update must behave as if it
> occurs when the xforms-insert event reaches the target instance
> element in the capture phase."
>
> The "index update" is mentioned in the two sentences so it is clear
> for that one, but what about adding the repeat items?
>
> First, I would reformulate this slightly differently:
>
> "The repeat index update on insertion must behave as if it occurs when
> the xforms-insert event reaches the target instance element in the
> capture phase. The repeat item generation on insertion must behave as
> if it occurs in response to the xforms-insert event dispatched by the
> insert action."
>
> Second, the text "in response to" above is unclear to me. We use "in
> response to" in the spec in general to say that an event is dispatched
> upon processing an action. So "in response to" means dispatching the
> event. But here in section 9.3.3 does that mean that item generation
> can occur at any time between during the event dispatch?
>
> I would also change:
>
> "The repeat index update on deletion behaves as if it occurs in
> response to the xforms-delete event dispatched by the delete action.
> Specifically, the index update behaves as if it occurs when the  
> xforms-
> delete event reaches the target instance element in the capture  
> phase."
>
> To simply:
>
> "The repeat index update on deletion must behave as if it occurs when
> the xforms-delete event reaches the target instance element in the
> capture phase."
>
> -Erik
>
> --
> Orbeon Forms - Web Forms for the Enterprise Done the Right Way
> http://www.orbeon.com/
>
>
>
>

--
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Wednesday, 20 August 2008 21:07:59 UTC

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