cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joerg Henne <>
Subject Re: [C2] Handling Redirects
Date Sat, 16 Dec 2000 15:28:57 GMT

Giacomo Pati wrote,
> IMO XSP pages should not use redirect. I think it's wrong by design. You
> should use a component that does not generate output at all (ie.
> Matcher, Selector, Action).

well, I agree that redirection is an out of band thing - something that does
not fit very well into XSP's concept. However, I think that it is a tool too
valuable for modeling applications to be ignored.

> We cannot introduce new XSP tags. The specification of the XSP language
> is not longer an authority of Cocoon because other projects implement
> XSP as well (ie. AxKit). New XSP elements must be discussed on the xsp
> mailing list.

I am aware of that. I really should have made it clearer in my earlier post
that my primary intention was to get a discussion going. Sorry for just
slamming a patch onto the list :-)

> What you'd like to introduce is exacly separating the code that you will
> put into the xsp:init section into an Action which signals the sitemap
> to do the rdirect or process further on.
>   <map:match pattern="myuri/*>
>     <map:act type="should-we-redirect">
>       <map:redirect-to uri="http://somewhere/else/{to-go}"/>
>     </map:act>
>     <map:generate type="serverpage" src="pages/{1}"/>
>     ...
>   </map:match>

The actor concept is a really powerful one and I agree that handling redirects
by using actors is a much nicer design, but after some pondering I still think
that there are cases that cannot be solved without redirects from within the
XSP logic. 
Please consider, for instance, cases in which the descision for a redirect has
to be made based on which particular logic blocks have been incorporated into
a XSP page. Suppose we have a logicsheet which defines a set of functionality
which requires the user to be logged in and another one which can be used
without being logged in. To solve this problem using actors, I see three
possible options:
1. "marking" those XSP pages that require a login in some way, e.g. by putting
them below a certain directory
2. having the XML author provide the information about which pages require a
login to cocoon, e.g. by editing the sitemap
3. anticipating the XSP generation stage from within the actor and analysing
which logic blocks are used

All three solutions don't seem very satisfying or elegant to me. Naturally,
I'd be glad to hear about other solutions I haven't come up with.

> I don't see why the ResourcePipeline object should handle page redirects
> if the XSP page can't handle it. What is the benefit of that? Can you
> further explain that?

The assumption is: redirecting is a process that completely breaks the
pipeline concept of cocoon. So, if we can't do without it, then make it break
it drastically <g>. Furthermore, using exceptions for redirect handling is a
fairly common concept in servlet development, I think. For instance, Enhydra's
presentation objects do it that way. Based on this assumption, the
ResourcePipeline seemed to be the most natural place to handle the redirect.

Another reason for using an exception is the fact that after a redirect has
been sent, no other output should be created anymore. The
Response.sendRedirect() method will cause tomcat to come up with the
appropriate headers and a default HTML page explaining the redirect. Any other
output will potentially mess up this default page, confuse the browser and
scare somebody's cat. This can only be guaranteed, if we keep the
ServerPagesGenerator from cleaning up unclosed tags causing output to be
generated or if there is a way to intercept xsp production before the
startDocument() has been issued. I agree that the exception stuff is
redundant, if this interception is possible.

Joerg Henne

View raw message