W3C home > Mailing lists > Public > www-forms-editor@w3.org > July 2007

Re: Submission with instance replacement and deferred updates

From: Mark Birbeck <mark.birbeck@x-port.net>
Date: Mon, 23 Jul 2007 17:25:06 +0100
Message-ID: <640dd5060707230925j1d9989e2i46422a93c52f414c@mail.gmail.com>
To: "John Boyer" <boyerj@ca.ibm.com>
Cc: ebruchez@orbeon.com, "Forms WG (new)" <public-forms@w3.org>, www-forms-editor@w3.org, www-forms-editor-request@w3.org

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.
Received on Monday, 23 July 2007 16:25:09 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 10 June 2009 18:12:15 GMT