forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Crossley <cross...@indexgeo.com.au>
Subject Re: overriding part of a skin
Date Thu, 11 Dec 2003 23:45:20 GMT
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. 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"/>
> </xmlcatalog>
> ...
> 
> then use your xslt task like so:
> ...
> <xslt ...>
>     <xmlcatalog refid="myForrestCatalog"/>
> </xslt>
> ...
> 
> 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.

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



Mime
View raw message