Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
From: "Carsten Ziegeler" <cziegeler@sundn.de>
To: <cocoon-dev@xml.apache.org>
Subject: AW: [Vote]: URL Rewriting was:[RT]: Session support
Date: Wed, 10 Oct 2001 16:12:25 +0200
Message-ID: <GMEBIBHGAOFGJCDPJANDCEFLCOAA.cziegeler@sundn.de>
MIME-Version: 1.0
Importance: Normal
In-Reply-To: <3BC440F5.F3DF8FFD@apache.org>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

> Stefano Mazzocchi wrote:
>
> 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.

No problem! In fact I'm very lucky that someone is willing to discuss this
further although I fear that I don't have the right underwear right now...
(OK, we should search for a new running gag).

>
> 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
> hand.
>
Agreed!

> In short, people use to pass parameters to webapps using URI params, so
> you see stuff like
>
>  http://host/webapp/resource?session=&page=1&format=pdf
>
> but in cocoon is easier and suggested to do some inside-encoding of the
> URI such as:
>
>  http://host/webapp/resource/8394840984098309480/page1.pdf
>
> or
>
>  http://host/webapp/resource[8394840984098309480](1).pdf
>
> or
>
>  http://host/webapp/resource[1].pdf(8394840984098309480)
>
> 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.
>
Ok, I think a see the problem, I choose a wrong name for my intention:
it should rather be a *urlencoder* which does exactly what the encodeURL
method of the javax.servlet.http.HttpResponse object does and currently
nothing else.
So there exists exactly one *urlencoder* for a request which is passed
to the used serializer in the same way the current output stream is
set today.

> 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.
>
Yes, I totally agree, but I wanted to concentrate in the first run simply
on session handling. Unfortunately the way sessions are handled is not
a task Cocoon does, this is done by the servlet engine (or more generally
by the Environment). Therefore the way urls are rewritten for session
handling
is not the scope of Cocoon. And that's why I choose the simple solution
for this one task.

But it would be great to have a generatl real url rewriting mechanism for
dynamic information! Go for it :-)

> 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.
Agreed, as (hopefully) made clear above, this was not my intention -
there is nothing to configure on a serializer - a serializer must be aware
of this *urlencoding*.

>
> 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.
Hm, yes this is the question to answer! If I add a link to my content, I
don't want to care about session handling - the link should simply work
with or without a session.
I know there are many solutions out there which require that you mark a link
so it can be encoded by the container - but that's really annoying.
I agree, that the serializer might not be the best place for it, but
it must be transparently without the aid of the user.

>
> 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
>
>  http://host/webapp/resource[1].pdf(8394840984098309480)
>
> would be created using
>
>  cocoon:/resource[{page}].pdf({sessionID})
>
> that would be both translated and rewritten transparently.
>
Ok, I think I get your point. For usual url rewriting for any dynamic
information this might be suitable, but not for session handling as
you can't tell the servlet engine where the session id is stored in
the url (And this is indeed a missing feature, I think - or is it
there and I never saw it?).

> It's still a RT, but hopefully it shows my point.
>
Yes, absolutely. And I still think that we have two different concerns:
general url rewriting and session handling. One solution is of course
to take over the session handling.....

Carsten

> Stefano.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org