forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Koberg <>
Subject Re: overriding part of a skin
Date Fri, 12 Dec 2003 00:32:45 GMT

David Crossley wrote:

> Robert Koberg wrote:
>>David Crossley wrote:
>>>Robert Koberg wrote:
> <snip/>
>>>Good idea Robert. I have always wanted to try using the
>>>Catalog Entity Resolver for other tasks.
>>>Do you have an example of how to implement it?
>>If we are talking about Ant's xmlcatalog (as opposed to
>>the xml-common's catalog resolver, right?), ...
> They are one and the same. 

I would love it if you could tell me how I could use Ant's xmlcatalog 
interchangeably with the xml commons catalog or vice versa.

> The Ant xmlcatalog task
> allows us to use it at build-time. Also the Ant xmlcatalog
> can refer to Forrest's default catalog.xcat file for all
> the standard mapping to DTDs and stuff.
>>then something like this would do it:
>><xmlcatalog id="myForrestCatalog">
>>   <entity publicId="document2html"
>>     location="${my.forrest.xsl}/document2html.xsl"/>
>>   <entity publicId="whatever"
>>     location="${my.forrest.xsl}/foo.xsl"/>
>>   <entity publicId="configXml"
>>     location="${my.forrest.config}/boo.xml"/>
>>then use your xslt task like so:
>><xslt ...>
>>    <xmlcatalog refid="myForrestCatalog"/>
>>It would be somewhat similar if not using ant for transforms
>>and using the standard xml-commons catalog resolver (I will
>>provide an example if needed). I have not been following forrest
>>too closely as the site.xml, so if this does not work just say so.
> This is the problem. Skins are assembled by the sitemap and not
> by an Ant task, so that happens via Cocoon at forrest run-time.
> Therefore we would need to declare the mappings in
> src/core/context/resources/schema/catalog.xcat
> and use the main entity resolver.


There is a point when the child must leave the nest and fly off on their 
own. It must be the holiday season.., but I see forrest is to cocoon 
like the child is to their mother. At some point interests and needs 
diverge. (I am kinda waiting...)


> However, configurable paths to the XSLs are the issue. I suppose
> that we could dynamically generate an additional catalog.xcat at
> build-time and reference that from the main one.
> --David

View raw message