cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ramy Mamdouh <>
Subject Re: [control flow] changes and new sample
Date Sun, 08 Sep 2002 14:08:16 GMT

Ovidiu Predescu wrote:

> Hi Ramy,
> On Friday, September 6, 2002, at 11:02 AM, Ramy Mamdouh wrote:
>> Hello,
>> Being working on a project that uses the Control Flow extensively, 
>> made me a big fan of this great piece of software.
> This is great! Please do let me know if you encounter any problems 
> with it.
>> However, I have some comments here :
>> 1- sendPage() and the cocoon:/ protocol :
>> As I stated before, why the enforcement of using the "cocoon:/" 
>> protocol inside AbstractInterpreter.forwardTo() to make the 
>> redirection??
> Sorry, I forgot about this. Thanks for reminding me about it.
>> ---
>> PipelinesNode.getRedirector(environment)
>>        .redirect(false, "cocoon:/" + URI);
>> ---
>> This enforces any URI passed to the sendPage() to use the cocoon:/ 
>> protocol, which doesn't work for some situations.
>> For example, I couldn't use the Portal framework with it as far as I 
>> tested.
>> And currently I've changed the above method to make the protocol 
>> optional, meaning that the caller to sendPage() specify also the 
>> protocol to be used in redirection, I also had to save the 
>> continuation ID in session when the cocoon:/ protocol is not used.
>> So, I'm thinking that the sendPage() shouldn't enforce the use of the 
>> cocoon:/ protocol, what do you think?
> Can you please explain in more detail what the problem was with the 
> redirection using the cocoon:/ protocol and the Portal framework? I 
> don't see where an issue could appear. You almost always want the page 
> to be redirected to an internal pipeline. 

In general, the problem of the cocoon:/ protocol happens when you 
redirect to a complete sub-system (like Portal) where some links and 
actions depend on the location of this sub-system (its URI).

I mean the cocoon:/ protocol actually retrieves the content of the 
passed URI, and embed that content inside the space of the caller URI, 
So, if the sub-system you redirects to expects that, say, "index.html" 
is the main URI where form actions and such are passed to, everything in 
this sub-system will be broken.

In the portal framework, you define the main portal uri like : 
<portal-uri>index</portal-uri>, where this URI contains the portal 
generator responsible for getting all the coplets up and running, and 
also to *receive* the coplets commands like minimize, etc.
Using the internal protocol with the portal (or any other sub-system 
that behaves the same) would break the functionality of that sub-system.

> Perhaps a better solution is to remove the "cocoon:/" string from the 
> AbstractInterpreter.forwardTo() method and put it in the system.js 
> sendPage() function, which at least could be redefined. What do you 
> think? 

That's much better ofcourse, but what about making some overloaded 
sendPage() methods, the default one uses the cocoon:/protocol, the other 
one accepts a protocol as a parameter, sendPage(uri, prototcol) or 
something like that.

One more thing, The storing of the Continuation object. I think 
currently, you store it in the Environement.
I think This wouldn't work when redirecting to an external URI (not 
using the cocoon:/ I mean), so maybe the other overloaded method would 
be responisble for storing the Continuation object in the session.

>> 2- XSP :
>> On the project I'm working on, we don't use XSP.
>> And so, we don't have any means to get the Continuation ID, thus 
>> We've made a simple ContinuationTransformer and ContinuationAction 
>> that makes using the Control Flow possible for not XSP based 
>> applications.
> This is nice, would you care to contribute them? 

Ofcourse, we gonna send them ASAP.

>> Finally, Although I consider Cocoon is a really magical thing, I do 
>> think that the Flow Control is one of the most exciting stuff I've 
>> seen since I knew about web programming.
> Oh, thank you very much! I'm glad you like the concept, I'll try to 
> improve it even more.
> Best regards,

Ramy Mamdouh Kamel

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

View raw message