You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by Dave Brondsema <da...@brondsema.net> on 2003/12/11 16:25:20 UTC
overriding part of a skin
For a while I've been overriding just document2html.xsl of krysalis-site.
Now I need to have the entire skin, and the "common" skin directory in my
project's source directory. If I don't, I get errors like 'root'
variable not found, or 'pdflink' template not found.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - Calvin club
Re: overriding part of a skin
Posted by Robert Koberg <ro...@koberg.com>.
David Crossley wrote:
> Robert Koberg wrote:
>
>>Hey,
>><snip/>
>>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...)
>
>
> I am not sure why i waste my time replying to this.
>
> Does the child cut out its internal organs and leave them
> at the front door of their parent's house?
OK :)
I would say keep your organs, just cut the cord.
But, really what does cocoon do for this project that cannot be handled
by (relatively) simple transformations?
It is my understanding that forrest is for offline generation of
(apache) docs (I had thought it was for more). Why do you need the power
of cocoon for this? Is it the general lack of understanding of XSL? I
guess that is a valid concern (though not what I would expect here), but
not an excuse.
Complicating things, like what is done in forrest, does not make things
simpler, right? I have spent a good amount of effort into showing how
easy and powerful a more simple way can be -- check the archives (here
and in cocoon) about what is possible. I could reiterate... If that is
what you would like, it will probably have to wait till tomorrow.
best,
-Rob
>
> --David
>
>
Re: overriding part of a skin
Posted by David Crossley <cr...@indexgeo.com.au>.
Robert Koberg wrote:
> Hey,
> <snip/>
> 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...)
I am not sure why i waste my time replying to this.
Does the child cut out its internal organs and leave them
at the front door of their parent's house?
--David
Re: overriding part of a skin
Posted by Robert Koberg <ro...@koberg.com>.
Hey,
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"/>
>></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.
OK.
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...)
best,
-Rob
>
> 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
>
>
Re: overriding part of a skin
Posted by David Crossley <cr...@indexgeo.com.au>.
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
Re: overriding part of a skin
Posted by Robert Koberg <ro...@koberg.com>.
Hi David,
David Crossley wrote:
> Robert Koberg wrote:
>
>>Dave Brondsema wrote:
>>
>>
>>>I don't think we should require common to be present in the
>>>src directory. Can the custom skins do something like:
>>>
>>><xsl:import
>>>href="concat($forrest-skins-dir,'/common/xslt/html/document2html.xsl"/>
>>
>>No (XSL cannot do this), but you could do something like:
>>
>><xsl:import href="document2html"/>
>>
>>and use the catalog resolver to identify what should be imported.
>
>
> 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?), 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.
best,
-Rob
>
> --David
>
>
Re: overriding part of a skin
Posted by Nicola Ken Barozzi <ni...@apache.org>.
David Crossley wrote:
> Robert Koberg wrote:
>
>>Dave Brondsema wrote:
>>
>>>I don't think we should require common to be present in the
>>>src directory. Can the custom skins do something like:
>>>
>>><xsl:import
>>>href="concat($forrest-skins-dir,'/common/xslt/html/document2html.xsl"/>
>>
>>No (XSL cannot do this), but you could do something like:
>>
>><xsl:import href="document2html"/>
>>
>>and use the catalog resolver to identify what should be imported.
>
> 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 make users use the skin download facility, this should not be
needed in any case IIUC, as the downloaded skins are placed right next
to the standard Forrest skins.
It's nevertheless a good idea.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
Re: overriding part of a skin
Posted by David Crossley <cr...@indexgeo.com.au>.
Robert Koberg wrote:
> Dave Brondsema wrote:
>
> > I don't think we should require common to be present in the
> > src directory. Can the custom skins do something like:
> >
> > <xsl:import
> > href="concat($forrest-skins-dir,'/common/xslt/html/document2html.xsl"/>
>
> No (XSL cannot do this), but you could do something like:
>
> <xsl:import href="document2html"/>
>
> and use the catalog resolver to identify what should be imported.
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?
--David
Re: overriding part of a skin
Posted by Robert Koberg <ro...@koberg.com>.
Dave Brondsema wrote:
>
> I don't think we should require common to be present in the src directory.
> Can the custom skins do something like:
>
> <xsl:import
> href="concat($forrest-skins-dir,'/common/xslt/html/document2html.xsl"/>
>
> instead of:
>
> <xsl:import href="../../../common/xslt/html/document2html.xsl"/>
No (XSL cannot do this), but you could do something like:
<xsl:import href="document2html"/>
and use the catalog resolver to identify what should be imported.
best,
-Rob
Re: overriding part of a skin
Posted by Dave Brondsema <da...@brondsema.net>.
On Thu, 11 Dec 2003, Ross Gardler wrote:
> Dave Brondsema wrote:
> > For a while I've been overriding just document2html.xsl of krysalis-site.
> > Now I need to have the entire skin, and the "common" skin directory in my
> > project's source directory. If I don't, I get errors like 'root'
> > variable not found, or 'pdflink' template not found.
>
> This only happens in CVS head version of Forrest and is due to the move
> to editing in src. And will only happen if you override skins rather
> than create a custom skin. I'm not sure it was ever intended that people
> override parts of skins. If it is/was then this is a backward
> compatability problem and should be addressed.
I don't know if that was intended, but it did work. I think it's fine
to require whole custom skins.
>
> The problem is that skins are no longer copied over to the webapp
> directory. As a result if you use a custom skin it must be complete and
> common must also be present in your src directory. In the past if you
> had a skin in your src with the same name as a skin in forrest itself
> you could override portions of the skin.
>
I don't think we should require common to be present in the src directory.
Can the custom skins do something like:
<xsl:import
href="concat($forrest-skins-dir,'/common/xslt/html/document2html.xsl"/>
instead of:
<xsl:import href="../../../common/xslt/html/document2html.xsl"/>
> I'm not sure overriding parts of a skin is a good idea as this opens you
> to unexpected errors when the original skin is updated (this is why
> common is required in src for a custom skin that uses it).
>
Quite true; I have had a few problems requiring merges between
krysalis-site and my override.
--
Dave Brondsema
dave@brondsema.net
http://www.brondsema.net - personal
http://www.splike.com - programming
http://csx.calvin.edu - Calvin club
Re: overriding part of a skin
Posted by Ross Gardler <rg...@wkwyw.net>.
Dave Brondsema wrote:
> For a while I've been overriding just document2html.xsl of krysalis-site.
> Now I need to have the entire skin, and the "common" skin directory in my
> project's source directory. If I don't, I get errors like 'root'
> variable not found, or 'pdflink' template not found.
This only happens in CVS head version of Forrest and is due to the move
to editing in src. And will only happen if you override skins rather
than create a custom skin. I'm not sure it was ever intended that people
override parts of skins. If it is/was then this is a backward
compatability problem and should be addressed.
The problem is that skins are no longer copied over to the webapp
directory. As a result if you use a custom skin it must be complete and
common must also be present in your src directory. In the past if you
had a skin in your src with the same name as a skin in forrest itself
you could override portions of the skin.
I'm not sure overriding parts of a skin is a good idea as this opens you
to unexpected errors when the original skin is updated (this is why
common is required in src for a custom skin that uses it).
Ross