Re: Submission with instance replacement and deferred updates

Ah, good to know.

But what do you think of Erik's idea here to *set* the deferred update 
flags after submission, rather than doing the actions?

I think I know where he is coming from... that a 'send' action could be 
followed by further processing before 
rebuild-recalculate-revalidate-refresh.

This idea seems reasonable if submissions were synchronous, but the fact 
that submission is asynchronous (by default) seems to be where it falls 
down...

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





"Mark Birbeck" <mark.birbeck@x-port.net> 
Sent by: www-forms-editor-request@w3.org
07/23/2007 09:25 AM
Please respond to
mark.birbeck@x-port.net


To
John Boyer/CanWest/IBM@IBMCA
cc
ebruchez@orbeon.com, "Forms WG (new)" <public-forms@w3.org>, 
www-forms-editor@w3.org, www-forms-editor-request@w3.org
Subject
Re: Submission with instance replacement and deferred updates







Oops...You are right John. I was indeed thinking of the recent discussion. 
:)

On 23/07/07, John Boyer <boyerj@ca.ibm.com> wrote:
>
> 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/
>
>
>



-- 
  Mark Birbeck, formsPlayer

  mark.birbeck@x-port.net | +44 (0) 20 7689 9232
  http://www.formsPlayer.com | http://internet-apps.blogspot.com

  standards. innovation.