cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Man <>
Subject Re: [c2] simple question on map:redirect-to semantics
Date Sun, 20 May 2001 18:00:23 GMT
On Sat, May 19, 2001 at 05:30:52PM +0200, giacomo wrote:
> On Sat, 19 May 2001, Martin Man wrote:
> 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".
that's true and I don't like context:// here neither, but I think we can agree
upon that /sub1/foo/bar is useless (ok, not completely :-)) (it breaks 
the context independency) and ../foo/bar is too awkward to be universal

so what then ?
> Comments?
> Giacomo

"Only dead fish swims with a stream"
gpg_key_fingerprint: 2CC0 4AF6 92DA 5CBF 5F09  7BCB 6202 7024 6E06 0223

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

View raw message