cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ovidiu Predescu <>
Subject Re: Deciding Flowscript <-> Sitemap hooks [was: Re: Changes made to flow system.js]
Date Wed, 11 Dec 2002 07:37:58 GMT

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.

> Anyway, feel free to ignore this discussion if you don't care about it.

Ahem, but would you ignore a discussion that consumes such a bandwidth? 

>> 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.

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.

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 

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 

I hope this doesn't sound offensive, it's certainly not meant to be so.

Best regards,

Ovidiu Predescu <>

To unsubscribe, e-mail:
For additional commands, email:

View raw message