cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Suck" <olis-mailingli...@gmx.de>
Subject [C2] Content Aggregation and getRequestURI()
Date Wed, 31 Oct 2001 10:18:44 GMT
Hi Cocooners,

I am trying to build a complete URL inside a Saxlet by using the methods
defined in org.apache.cocoon.environment.Request.

Depending on the fact whether or not there was a content aggregation in the
(sub)sitemap, request.getRequestURI() returns different results (request is
an instance of org.apache.cocoon.environment.wrapper.RequestWrapper).

A partial sub sitemap is included at the end of this message.

With content aggregation (browser URL
http://localhost:8088/cocoon/subsite/foo/index.xml.html) I get the
following results:
request.getContextPath(): "/cocoon"
request.getRequestURI(): "subsite/template/foo/index.xml"
request.getSitemapURI(): "template/foo/index.xml"
(The fragment "template" comes from the section
<map:part src="cocoon:/template/{1}/{2}"/> and shall be ignored here.)

Without content aggregation (browser URL
http://localhost:8088/cocoon/subsite/foo/index.xml.html.foo) this looks
like:
request.getContextPath(): "/cocoon"
request.getRequestURI(): "/cocoon/subsite/foo/index.xml.html.foo"
request.getSitemapURI(): "foo/index.xml.html.foo"

After digging through the developer mailing lists I have found a discussion
related to that specific topic back in May this year (see
http://www2.real-time.com/pipermail/cocoon-devel/2001-May/007294.html).
Unfortunately it seems as if the thread of this topic was not finished
completely (in case I missed it - sorry for that).

The documentation of the Request Interface puts it that way:
getRequestURI()
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.

Now here is the question considering the method desciption:
Is request.getRequestURI() really supposed to return only a part of the
original requestURI (i.e. with the contextPath ripped off)? - As you can see
in the example without content aggregation, getRequestURI() includes the
contextPath, whereas in the example using content aggregation, the
contextPath was removed.

How do I have to build a complete URL from the Request's methods then?
In cases without content aggregation, to me it looks like "take the
request's scheme, append the serverName, append the port if necessary,
add the requestURI and there you go (not mentioning slashes and colons)".
How can I decide inside the Java code whether there was content
aggregation or not and how the URL should be built? Just checking whether
the requestURI starts with the contextPath? Sounds a little too easy.

Still new in this area, so don't blame me for silly questions. ;-)

Thanks in advance!
Oliver.




<!-- partial sub site map -->

 <map:pipeline>
  <!-- Example with content aggregation -->
  <map:match pattern="*/**.html">
   <map:aggregate element="aggregatedpage">
    <map:part src="cocoon:/template/{1}/{2}"/>
    <map:part src="cocoon:/content/{1}/{2}"/>
        <!-- {2} not used in this example -->
   </map:aggregate>
   <map:transform src="docs/{1}/template.xsl"/>
   <map:serialize/>
  </map:match>
  <!-- Example without content aggregation -->
  <map:match pattern="*/**.html.foo">
   <map:generate src="docs/{1}/template.xml" type="saxlet"/>
   <map:serialize/>
  </map:match>
 </map:pipeline>
 <map:pipeline internal-only="true">
  <!-- Process the aggregated content -->
  <map:match pattern="template/*/**">
   <!-- XML page template -->
   <map:generate src="docs/{1}/template.xml" type="saxlet"/>
   <map:serialize/>
  </map:match>
  <map:match pattern="content/**">
   <!-- XML content file  -->
   <map:generate src="docs/{1}" type="file"/>
   <map:transform src="stylesheets/content.xsl"/>
   <map:serialize/>
  </map:match>
 </map:pipeline>






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


Mime
View raw message