> [EMAIL PROTECTED] 12/10/02 03:36PM >So, my proposal would be Could we split this function:
> sendScreen(uri, data); into sendPage: > - sends the screen containing a form that will trigger a POST action that will go >back here and getReply: > - blocks the execution of the flow until a request with the matching continuation ID >comes back > - returns with the cocoon.* objects filled with the latest client data and keep this function as is: > sendPage(uri, data); > - sends a page (no further rountripping is expected from that page so no state is >transparently preserved) Maybe that is what you are saying here: >I have an alternative proposal, even if this requires more changes to the system: >Instead of "sendScreen", why don't we do: > var objectModel = getClientInput(uri,data); >then > sendPage(uri); > >getClientInput will *implicitly* have a blocking semantics. I know this >explicitly outlines the third step, but IMO this solves one cognitive >problem that I had when Ovidiu first described the flow: how I get the >client data back from sendPage()? > >Having the data *explicitly* returned from the method invocation is, >IMO, a *GREAT* help. > >What do you think? I like it if you are suggesting the following semantics: sendForm -- send a page that expects a reply, but do not block for the reply getReply -- block for the reply to the previous sendForm sendPage -- send a page that does not expect a reply This allows the continuations to be managed properly even though sending the form and getting the reply are split into two functions. Then we could do this: Send a form Do time consuming work that *does not* need the reply data Block for the reply Do the remaining work that *does* need the reply data Send the next form Tim > [EMAIL PROTECTED] 12/10/02 03:36PM ... >>Christopher Oliver wrote: ... >> 2) Explicitly identify the input page, such as >> >> sendForm(uri, bizData); // block waiting for user input; >> cocoon.request contains the submitted request after this returns >> >> and >> >> sendPage(uri, bizData); // send a page that won't return here; >> cocoon.request is invalid after this returns > >Ohhhh, nice!!! > >What I like about this is that semantics are abstract enough to mean >anything, but they don't confuse people! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
