Re: Submission with instance replacement and deferred updates

Hmm, actually when it was discussed, a very long time ago, I don't think 
setting the flags was even discussed.  The main discussion was about 
whether the actions should be triggered by events versus performed 
directly.

Mark, perhaps you are thinking about the new submission behavior that now 
*precedes* submission, in which rebuild and recalculate are performed if 
the flags for those operations are already set.

It was previously decided that the direct actions would be performed, 
rather than dispatching events, to ensure that the 
rebuild-recalculate-revalidate-refresh sequence was not cancelled by 
measures a form author might have taken to cancel "automatic" 
recalculations that occur during the fill experience.  I can't say I ever 
really found the use case compelling, but that's another story.

I don't recall any action items or prior discussions about having 
submission modify the deferred update flags.  Since it is not an XForms 
action, it is only recently that we even considered having submission 
*read* the flags.  Having it also write the flags is an interesting idea, 
though.  As long as we also make sure that the deferred update happens for 
a submit control, it seems a nice generalization that gets rid of some 
perhaps unwanted behavior while also making things more consistent.

Cheers,

John M. Boyer, Ph.D.
STSM: Lotus Forms Architect and Researcher
Chair, W3C Forms Working Group
Workplace, Portal and Collaboration Software
IBM Victoria Software Lab
E-Mail: boyerj@ca.ibm.com 

Blog: http://www.ibm.com/developerworks/blogs/page/JohnBoyer





Erik Bruchez <ebruchez@orbeon.com> 
Sent by: www-forms-editor-request@w3.org
07/23/2007 08:51 AM
Please respond to
ebruchez@orbeon.com


To
"Forms WG (new)" <public-forms@w3.org>
cc
www-forms-editor@w3.org
Subject
Re: Submission with instance replacement and deferred updates







Then that's great and I hope there is an action item out there to track 
this.

-Erik

Mark Birbeck wrote:
> Hi Erik,
> 
> When this was discussed we definitely agreed that it should be a case
> of 'set the flags'.
> 
> Regards,
> 
> Mark
> 
> On 23/07/07, Erik Bruchez <ebruchez@orbeon.com> wrote:
>>
>> All,
>>
>> This issue may have been raised before, but I just hit it again when
>> implementing some optimizations in our implementation, and I would
>> like to make sure that it is discussed if not already done. You never
>> know, John has so many action items ;-)
>>
>> Section "11.2 The xforms-submit Event", upon instance replacement,
>> directly performs rebuild, recalculate, revalidate and refresh
>> operations. My question is simple: why do we do this directly, rather
>> than setting the flags?
>>
>> This in particular is inconsistent with the way xforms:insert
>> works. See section "9.3.5 The insert Action", point 9, where the flags
>> are set:
>>
>>    "The XForms action system's deferred update flags for rebuild,
>>     recalculate, revalidate and refresh are set."
>>
>> An instance replacement is not different from an insert action, in
>> that an entire instance or part of it may be replaced. The two should
>> work consistently.
>>
>> If we want to be consistent, which option to choose? I do not see a
>> particular reason why a submission with instance replacement would
>> work differently from any other action in XForms, so I do think that
>> the consistency would work in favor of modifying the behavior of
>> submission to set the deferred update flags.
>>
>> That is, unless there is a very good reason to perform these actions
>> directly, but at this point I don't see any, and I suspect that this
>> is just a legacy from XForms 1.0 prior to the more refined work on
>> deferred updates done in 1.1.
>>
>> -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/