<snip/>
Thinking further about this, we have to define carefully how this relates to the "cocoon:" protocol, because in such a case we have _two_ request paths :
- the protocol-level path, accessible using getRequestURI(),
- the sitemap-level path, accessible using getSitemapURI() (different from the above in the case of a mount or "cocoon:")
Hm... you are right
We also have to consider that, through getSitemapURI(), the "getSitemapXxx" names are tied to the current sitemap request (i.e. the "cocoon:" one).
IMO, the use case is more related to the protocol-level URI :
I aggree <snip/>
I have the same use case - and same view :)But this is only my view of the problem. Any other use case ?
...but I am really wondering if there aren't any use cases not only related to the protocol level. Anyone?
We also have to consider how to handle the interface change :
- on 2.1, no problem : we're not even alpha ;-)
- on 2.0, there can be some backwards compatibility for people having implemented their own Request without extending one of the provided classes. Are there many of them ? I would say no, but if there are, please stand up !
Hm... changing an core interface in 2.0? I guess I am -0 on that... ...maybe we should ask on cocoon-users? -- Torsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
