cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From giacomo <giac...@apache.org>
Subject Re: [c2] problem with content aggregation (fwd)
Date Fri, 04 May 2001 21:31:11 GMT

On Fri, 4 May 2001, Donald Ball 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.

Giacomo

>
> ---------- Forwarded message ----------
> Date: Thu, 3 May 2001 22:03:27 -0400 (EDT)
> From: Donald Ball <balld@webslingerZ.com>
> To: cocoon-dev@xml.apache.org
> Subject: [c2] problem with content aggregation (fwd)
>
> okay, i came up with a solution to the problem - i was wrong to blame c2
> for messing with getPathInfo - catalina's request object always returns
> null for this method when i call it! anyway, i added a method to the c2
> Environment and Request objects - getRootRequestURI. a patch is attached
> which implements this for the http implementations (commandline returns
> null). however, i think we should think about coming up with something
> else - Request.getRequestURI is documented to do this:
>
>      * Returns the part of this request's URL from the protocol
>      * name up to the query string in the first line of the HTTP request.
>      * For example:
>
> but in actuality, it returns the request URL after the context path has
> been stripped and possibly the URL has been mangled through the sitemap's
> content aggregation system. i would say that getRequestURI should return
> the request URI as returned by the underlying servlet request object, and
> we should add a new method to the Request object to return the c2 sitemap
> URL.
>
> for example, if my webapp is mounted under /webapp, and my sitemap has the
> following rule:
>
> <map:match pattern="foo">
>  <map:aggregate>
>   <map:part src="bar" type="serverpages/>
>  </map:aggregate>
> </map:match>
>
> if i request /webapp/foo, getRequestURI() will return "/webapp/foo",
> getContextPath() will return "/webapp", and calling getSitemapURI() inside
> the "bar" server page will return "bar". calling getSitemapURI() from
> elsewhere in the pipeline will return "foo". thoughts?
>
> - donald
>
>
>
> ---------------------------------------------------------------------
> 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


Mime
View raw message