<snip> >> 3) Punt on distinguishing this behavior with the name of the function. >> Just add a third (optional) boolean parameter to indicate if it should >> block >> >> sendPage(uri, bizData, waitForInput); > > I like the above better. > > What I mostly like is the distinction between a 'form' and a 'page'. > > The way I've been programming web application is that POST and GET > actions should be connected to the same resource. > > I mean, if I have to POST something, first of all I GET it, then fill up > the form, then POST it, then get results. All good webapp frameworks try > to enforce the notion of this in-resource roundtripping. > > This is also because a page can contain *more* than one form. > > For this reason, I would propose to change the notion from 'form' to > 'screen' to avoid having the semantic collision between what a 'form' is > for flow and what a form is for HTML. > > So, my proposal would be > > sendScreen(uri, data); > > - sends the screen containing a form that will trigger a POST action > that will go back here > - 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 > > sendPage(uri, data); > > - sends a page > (no further rountripping is expected from that page so no state is > transparently preserved)
Ugg, although I can see a semantic difference between a form and a page I'll be darned if I can see a semantic difference between a screen and a page (given that we're not dealing with page oriented media in most cases anyway)... > - o - > > 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. Seems much better to me! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
