On Tuesday, Dec 10, 2002, at 12:36 US/Pacific, Stefano Mazzocchi wrote:
Ovidiu, I know that some of you are somewhat frustrated by this 'apparently nonsense' discussion on some trivial things like function names, but I personally think that a great deal of information was exchanged between people on flow and this is a great thing.Yes, indeed, this discussion helped clarify a lot of misunderstanding people had about flow. I've never said it was nonsense, I just wanted to reach a logical conclusion. I'm concerned about the bandwidth we spend on such unimportant issues, instead of discussing the real meat of the problem. It's getting more and more a discussion about form instead of content.
Also, I think Chris is right on target with this, so, if you don't mind, I'll continue the discussion until we have reached consensus.Chris helped indeed a great deal in clarifying the misunderstanding I mentioned above. It looks like some of them still persist, I'll reply to some of those later in this message.
I know that javascript allows you to redefine your function names easily, but that's working around the problem and it doesn't help to create consensus, without with the community might develop friction and frustration even more than during the discussions.I don't think naming conventions will create frictions in the nice community of people we have here, it's the design issues which usually create frictions. From this thread however, I see discussed only function names, and not the design aspects of the control flow. I don't a consensus can be reached on names, so IMO it's better to decide on something good enough and stick with it.
Ahem, but would you ignore a discussion that consumes such a bandwidth? ;)Anyway, feel free to ignore this discussion if you don't care about it.
The original sendPage() function already returns something: it's the continuation object. This object cannot be returned in any other way from sendPage(). Even though normal users will never use it, it's still a good idea to have that object available for advanced scripts.So here are some other possibilities:[...]
[...]
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
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)
- 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.
Stefano, all the API change proposals I've seen so far can be implemented easily in few lines of code in JavaScript. My take on this is that is not worth spending our time (not to mention eating Apache's bandwidth ;) analyzing each and every possible API we can come up with. Instead of doing that, we can have the simple API already in place, and build on top of it, or rip it apart and implement a custom one in various applications. We'll see later what works and what not. And since each application is unique, experienced developers will come up with their own higher level abstractions on top of what is already here. This is not an issue at all, there are always better ways to do things.
We desperately need some documentation for the current features and various other things to be finished, before this stuff can become production quality. I'd suggest these naming discussions to stop here, and instead focus on the places where the real work still needs to be done. My time is limited, so I'd really appreciate any help in those areas.
I hope this doesn't sound offensive, it's certainly not meant to be so.
Best regards,
Ovidiu
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://webweavertech.com/ovidiu/weblog/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
