On Mon, Feb 10, 2003 at 02:09:17PM -0500, Ben Young wrote:
> Sorry Jeff, I guess I never gave an example of the what the proposed pipeline should
>look like.
>
> <map:match pattern="**/index.htm*">
> <map:act type="sourcetype" src="/home/htdocs/content/{1}/index.xml">
> <map:generate src="cocoon:/{../1}/index.{sourcetype}"/>
> </map:act>
> <map:transform src="/home/htdocs/design/shell.xsl">
> <map:parameter name="path" value="{1}"/>
> </map:transform>
> <map:transform type="cinclude"/>
> <map:serialize/>
> </map:match>
And doesn't it work? What is the output just before the cinclude?
(sorry, I still haven't twigged.. what does shell.xsl do?)
> I've looked into the Forrest site.xml work and I like it for the most
> part, but the thought of managing a single navigational map for an
> entire 7,000+ page site seems a bit unruly.
Ouch.. yes it would. With a sitemap tweak, site.xml could xinclude
site.xml's from subdirectories though.
> I'm trying to break it up into managable, human tolerant pieces. 8o)
> That, <sarcasm>oddly enough</sarcasm>, is proving to be a daunting
> task. 8o)
Oh well, *humans*, there's your problem :o) Upgrade to a species more
tolerant of complexity, and everything will be fine.
--Jeff
> Thoughts,
> Ben
>
> >>> Jeff Turner <[EMAIL PROTECTED]> 02/09/03 07:33 AM >>>
> On Fri, Feb 07, 2003 at 09:00:19PM -0500, Ben Young wrote:
> > I've recently attempted to use the cinclude to aggregate some files that I'm
> > currently aggregating with the map:aggregate command, but I've run into some
> > "issues" that I'm not sure how to resolve.
> >
> > My current map:match section looks like this:
> >
> > <map:match pattern="**/index.htm*">
> > <map:act type="sourcetype" src="/home/htdocs/content/{1}/index.xml">
> > <map:aggregate element="document">
> > <map:part src="cocoon:/{../1}/../_navigation.xml"
> > element="navigation"/>
> > <map:part src="cocoon:/{../1}/index.{sourcetype}"/>
> > </map:aggregate>
> > </map:act>
> > <map:transform src="/home/htdocs/design/shell.xsl">
> > <map:parameter name="nav_filename"
> > value="/home/htdocs/content/nav_home.xml"/>
> > <map:parameter name="path" value="{1}"/>
> > </map:transform>
> > <map:serialize/>
> > </map:match>
> >
> > I use an "internal-only" pipeline to find the nearest _navigation.xml file
> > in existence.
> >
> > <map:pipeline internal-only="true">
> > <map:match pattern="**/_navigation.xml">
> > <map:act type="resource-exists">
> > <map:parameter name="url"
> > value="/home/htdocs/content/{1}/_navigation.xml"/>
> > <map:generate src="/home/htdocs/content/{../1}/_navigation.xml"/>
> > <map:serialize type="xml"/>
> > </map:act>
> > <map:redirect-to uri="cocoon:/{1}/../_navigation.xml"/>
> > </map:match>
> > </map:pipeline>
> >
> > I'd like to move the aggregation step after the shell.xsl is applied. The
> > plan is to have the shell.xsl output a cinclude tag that uses the
> > "cocoon://" psuedo-protocol in the appropriate place using the $path
> > parameter plus "_navigation.xml"
> >
> > My current trouble is that the cinclude only runs through the internal
> > pipeline once.
>
> Perhaps my brain slipped out of gear, but that seems a bit cryptic..
> Don't you need a <map:transform type="cinclude"/> tag somewhere to get
> cinclude processing?
>
>
> --Jeff
>
> PS: in case you didn't know: Forrest does this kind of nav + body
> integration to generate pages like http://xml.apache.org/forrest/
>
>
> > Thank you for any help you might be able to give,
> > Ben
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
