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

Re: Submission with instance replacement and deferred updates

From: Erik Bruchez <ebruchez@orbeon.com>
Date: Tue, 24 Jul 2007 00:20:06 +0200
Message-ID: <46A52996.8090009@orbeon.com>
To: "Forms WG (new)" <public-forms@w3.org>

John Boyer wrote:
 >
 > 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...

Good point, but it is still reasonable IMO to consider that all the
updates to instance data which occur in a synchronous way, whether
caused directly by actions or indirectly by a submission, use the
flags mechanism.

An asynchronous submission, on the other hand, could do one of two
things:

* Synchronously perform the refresh, etc. when it's done.

* However, this would be a waste if by any chance there is another
   sequence of actions/events (for example a synchronous submission
   still waiting to complete) at the same time for the same model. Not
   all implementations may allow this to happen. But if it is allowed,
   in that case, and with careful synchronization, the asynchronous
   submission could still set the flags.

The choice of how exactly this should be done could be left to the
implementor, the condition being that after the submission completes,
somehow, refresh, etc. must be performed.

-Erik

-- 
Orbeon Forms - Web Forms for the Enterprise Done the Right Way
http://www.orbeon.com/
Received on Monday, 23 July 2007 22:20:10 UTC

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