cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Donald Ball <ba...@webslingerZ.com>
Subject [c2] problem with content aggregation (fwd)
Date Fri, 04 May 2001 00:39:59 GMT
i just took a gander at solving this and came up kinda empty. the
getPathInfo method for HttpRequest simply invokes the same method on the
underlying real HttpServletRequest object. the Environment object has
popURI and pushURI methods which the ContentAggregator uses, but i can't
see how the Request object interacts with them at all. *sigh*

- donald

---------- Forwarded message ----------
Date: Thu, 3 May 2001 16:02:51 -0400 (EDT)
From: Donald Ball <balld@webslingerZ.com>
To: cocoon-dev@xml.apache.org
Subject: [c2] problem with content aggregation

got a little dilemma here, guys. most of the pages in my c2 site are
created by aggregating some url-specific content and a site-specific
content:

   <map:match pattern="*">
    <map:aggregate element="root">
     <map:part src="plain/meta"/>
     <map:part src="plain/{1}"/>
    </map:aggregate>

this approach really kicks, it's like frames but better. anyway, one of
the things i'd like to do in the meta site-specific content area is to
include some links to the current url with some parameters tacked on the
end. e.g. if i've hit

/foo/clients

i might want to make some links to

/foo/clients?fontsize=12

or if i've hit

/foo/client?id=1

i might want to link to

/foo/client?id=1&fontsize=12

you get the idea. what i used to do was make the request.getPathInfo() and
request.getQueryString() variables available to my stylesheets using xsp
so i could construct the links there. unfortunately, that's not possible
when using content aggregation as the Request objects that the aggregate
parts receive return null for getPathInfo and getQueryString. i see two
ways to solve this:

1. have the sub Requests return the root Request's data for getPathInfo,
getQueryString, etc., but return their data for getRequestURI, etc.

2. give each sub Request a reference to its parent, so xsp authors can
access the root Request's data

(1) is probably a better option if it will never be the case that someone
will need access to both the child and the parent Request data. thoughts?

- donald





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


Mime
View raw message