- From: Erik Bruchez <ebruchez@orbeon.com>
- Date: Tue, 24 Jul 2007 00:20:06 +0200
- 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