cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: [Vote]: URL Rewriting was:[RT]: Session support
Date Wed, 10 Oct 2001 12:37:09 GMT
Carsten Ziegeler wrote:
> Hi Team,
> I guess, you all saw the recent thread about session support.
> I would like to add a new interface URLRewriter (name can be changed!)
> interface URLRewriter {
>      boolean isURLRewritingEnabled();
>      String  rewriteURL(String url);
> }
> This object is responsible for rewriting urls for session handling.
> In fact (if Cocoon is used as a servlet), the isURLRewritingEnabled
> returns only true if a session is available and the session is not
> determined by Cookies. The rewriteURL() is forwarded to the
> Response object.
> The SitemapOutputComponent interface should be extended by:
> - setURLRewriter(URLRewriter ur);
> A serializer *can* use this for url rewriting, e.g. the html
> serializer.
> This approach has only minimal changes to Cocoon and it would
> enable automatic session handling while maintaining cacheability
> of most responses (the serializer can check using isURLRewritingEnabled
> and if this is false the response can still be cached without problems).
> Such a change simplies writing web applications as you don't have
> to take care about how session handling works. If you look at other
> frameworks, e.g. WebObjects etc., they provide a similar solution.
> The other working solution would be to writer a special transformer.
> But you would need a transformer for each format supporting this (html,
> wml etc) and the user must always use the transformer/serializer as a
> pair. If he forgets it somewhere, the web applications is broken. I
> think Cocoon can and should do this better!
> So please let's vote about this and if we should include it in 2.0.

Hmmm, sorry to be a pain in the butt, but I think we need more reasoning
on this.

I see URL-rewriting a *major* piece of Cocoon architecture and since we
have URI matching and tokenization implemented very elegantely in the
sitemap, I'd love to have something equivalently powerful on the other

In short, people use to pass parameters to webapps using URI params, so
you see stuff like


but in cocoon is easier and suggested to do some inside-encoding of the
URI such as:






Now, this said, with the above interface you are providing a pluggable
way of performing url-rewriting (which is indeed a good thing), but
allows each component (for what I understood) to set its own rewriter.

You say that url-rewriting is required when the session is present and
cookies are not used. I believe this is just one of the many possible
needs for URI-encoding of dynamic information.

In fact, the "concern" of where to place information in the URI is the
sitemap administrator's, not the serializer programmer's. I should *not*
have to recompile or reconfigure the serializer in order to use a
specific url-rewriting implementation that places the session
information in the location I will expect it to be on my URI
tokenization in the sitemap.

So, I believe url rewriting should happen trasparently right before the
serializer and its rewriting logic should be controlled who writes the
link, not who writes the component.

How so?

My solution would be to augment the cocoon: protocol to understand curly
braces and expand them just like you'd do in attribute-value-templates
for XSLT. So, the URI


would be created using


that would be both translated and rewritten transparently.

It's still a RT, but hopefully it shows my point.


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

View raw message