cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <>
Subject Re: [c2] problem with content aggregation (fwd)
Date Sat, 05 May 2001 00:31:08 GMT
On Fri, 4 May 2001, giacomo wrote:

> > in the absence of any comments on this, i went ahead and patched it by
> > reverting Request.getRequestURI to call getRequestURL on the underlying
> > HttpServletRequest object and added a Request.getSitemapURI method.
> >
> > - donald
> Well, what should I say. It seems to me you haven't understand the
> concept around the request, the Environment, mounting sub contexts/URIs
> etc. Ok, let me explain:
> The Environment object is responsible to manage the contexts a sitemap
> resides. As stated in the xdocs/draft/sitemap-working-draft.xmap it
> should (some time) be possible to mount a sitemap residing in a cvs
> repository directly over the net or in a jar file.  And thus the
> Environment object also acts as an EntityResolver for all the files
> components get from the sitemap (ie. in the src attributes) so that
> nobody (sitemap administrator and component writer) has to be concerned
> of knowing the real context. They are rooted at the sitemaps location.
> One of the sitemap responsabilities is to manage its URI space and
> acting as the central dispatcher.
> Now the sitemap tells the Environment when to switch to a new context in
> the case of a <mount> element and also what part of the "real"
> RequestURI it should strip away so that components in a sub sitemap can
> act as if they where at the root of the context (seen from the URI space
> as well as from the context space). Because of that the initial
> implementation of the request object was that the getRequestURI method
> was delegated to the Environment object which is the only instance which
> exactly knows the corresponding URI for the state the request is in.
> Now this clear and simple concept is broken by the patch you've applied
> and IMO it is by no means clearer to a developer which get**URI is the
> right one and we have to support a model which I'm not happy about.

the old getRequestURI method didn't return the data that it was documented
to return. i patched it to actually do so, and provided an alternate
mechanism by which one could request the data that it had been returning.

i believe that getRequestURI should return just that - the URI of the
original request.  people sometimes need that data - to construct links
back to the current page along with some extra parameters, for instance.
clearly, components may also need to know the URI of the current pipeline
part in the context of the sitemap, and you can use getSitemapURI to get
that data.

what's unclear and not simple about this? if you were to revert my patch,
how would you go about accessing the url as requested by the http client?

- donald

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

View raw message