cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <>
Subject Re: New : internal redirects with "cocoon:" URIs
Date Wed, 27 Mar 2002 16:16:12 GMT
Piroumian, Konstantin wrote:

>>From: Sylvain Wallez [] 
>>Hi team,
>>I implemented internal redirects using the "cocoon:" pseudo-protocol. 
>>This is the Cocoon-equivalent to servlet request forwarding.
>>This means that writing
>>  <map:match pattern="">
>>    <map:redirect-to uri="cocoon:/index.html"/>
>>  </map:match>
>>will make a recursive call on the current processor to serve 
>>"index.html" without going back to the client browser.
>>This is also available in the Redirector used by actions. And 
>>as usual, 
>>"cocoon:/xxx" uses the current sitemap, and "cocoon://xxx" 
>>uses the root 
>But as I remember, there were something like that already:
><map:redirect resource="/path/to/pipeline" />
>Is it different from your version?
Yes, it's different because the above works only with a <map:resource 
name="/path/to/pipeline">. Internal redirect goes through the standard 
pipeline mechanisms : matchers, selectors, etc.

>>This feature will be especially usefull with the flow engine, 
>>since the 
>>flow script chooses the page that comes next and should be 
>>able to call 
>>this page without losing business data that may be stored as request 
>Just yesterday was thinking of that. Struts uses exactly that for flow
>processing, thus you can chain actions and select the  flow of processing
>based on the returned result from every action.
That's exactly the purpose. The need for this came from an off-list 
discussion with Ovidiu about the relationships between the flow engine 
and the sitemap. I suggested that is was more natural to base the 
contract of the sitemap only on URIs than on both URIs (for incoming 
requests) and resources (for pages called from the flow).

>>This is implemented in 
>>and used for now only by the treeprocessor (so I didn't update the 
>>samples to avoid to break them). Integration with the compiled engine 
>>should be fairly easy, but I'm sooo late on my paid work, so 
>>any takers 
>>are welcome.
>Btw, do we still need to support compiled version if we switch to
Mmmmh. I should be a little bit biased to answer this question 
impartially ;)

Anyway, integrating forwarding in the compiled engine means basically 
replacing all SitemapRedirectors by ForwardRedirector (with care taken 
of the additionnal constructor parameters). So I think it should be good 
to have it in both engines.


Sylvain Wallez
  Anyware Technologies                  Apache Cocoon 

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

View raw message