cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [c2] simple question on map:redirect-to semantics
Date Sat, 19 May 2001 15:30:52 GMT


On Sat, 19 May 2001, Martin Man wrote:

> On Fri, May 18, 2001 at 02:15:48PM -0400, Donald Ball wrote:
> > On Fri, 18 May 2001, giacomo wrote:
> >
> > > > > Have you tried using
> > > > >
> > > > >  <map:match pattern="foo/bar">
> > > > >    <map:redirect-to uri="../bat"/>
> > > > >  </map:match>
> > > >
> > > > sure, and that works, but i think it's ugly and hard to maintain if you
> > > > deal with deeply structured patterns. e.g. if i move foo/bar to
> > > > resources/foo/bar, i also have to change the redirect uri.
> > >
> > > Well, can you imagine what Stefano would say about that? Better plan you
> > > URI space!
> >
> > and i'm also sure that he'd recommend having a webapp-mount-point
> > independent way of writing webapp-absolute urls!
> >
> > <map:match pattern="foo/bar/bat/cat/dog">
> >   <map:redirect-to uri="../../../../bat"/>
> > </map:match>
> >
> > is much harder to parse (for people anyway) and maintain than
> >
> > <map:match pattern="foo/bar/bat/cat/dog">
> >   <map:redirect-to uri="context://bat"/>
> > </map:match>
>
> I'm +10 of allowing context-relative redirects, I think we all agreed upon it
> in the former "redirect" discussion but then it silently stopped. Right now we
> have redirects that comply with servlet-specs, but I'm sure we need
> context-relative redirects also (perhaps we can turn it around and make the
> context ones by default and absolute ones per explicit request???)
>
> really ugly example follows, like more the one with context://
>
> <map:redirect-to uri="/under/context"/>
> <map:redirect-to uti="/another_webapp" absoulte=yes"/>
>
> as donald said: it allows you to write portable and context-independent webapps.
> right now I have several webapps that make a use of absolute redirect and it
> IS really nasty hack and no it DOES not have anything to do with URI space
> planning ;-|

Ok, lets nail it down. What is the semantic of the <map:redirect-to>
element?

a) you can use the resource="resource-name" attribute to break out of
   the evaluation sequence into a predefined pipeline arragement.
b) you can use the uri="another-uri" attribute to let the environment
   decide how to handle it by using the redirect method a concrete
   Environment has to implement for the sitemap.

Now, a) is in the concern of the sitemap while b) is in the concern of
the environment. The term uri is something that I don't like very much
because if you imagine you have written a concrete Environment for lets
say Apache James (Java Apache Mail Enterprise Server) what is the
semantic of the uri= attribute there. Is it a bounce to say "this
address isn't in use anymore, please use the address ${uri}"? Or is it
forwarding the message to the address mentioned in the uri attribute?
And what sense does it makes naming this attribute "uri" in a
JamesEnvironment. But since I've no good alternative for an other name
better suited to abstract that meaning of the uri attribute lets keep it
as it is.

Speaking so we need to define how the concrete HttpEnvironment
interprets the string specified in the uri attribute for different
contexts the system is in.

               root-sitemap  sub-sitemap      sub-sub-sitemap
uri: foo/bar   /ctx/foo/bar  /ctx/sub/foo/bar /ctx/sub1/sub2/foo/bar
uri: /foo/bar  /ctx/foo/bar  /ctx/foo/bar     /ctx/foo/bar
uri: //foo/bar /foo/bar      /foo/bar         /foo/bar

A question remaining is "how do I specify in the sub-sub-sitemap a uri
for the sub-sitemap". Well either with ../foo/bar or with /sub1/foo/bar.

I don't like using a already used protocol specifier like context://
because it already has a semantic like "pointing into the file system
structure at the Environments root contexts". Using it in the uri
attribute will change that semantic "pointing into the uri space
structure at the Environments root uri space".

Comments?

Giacomo


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


Mime
View raw message