forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Tessner <>
Subject [copyless] Issues with //skinconf
Date Sat, 01 May 2004 19:10:25 GMT
Hi all,

There's a bit of an issue with the change to //skinconf (other than the
PDF one).

Using aggregation is a great idea for the skin configuration. 
Unfortunately, where it's being done means that some of the
configuration bits are not available when desired.

In particular, any requests for configuration information done by
document2html.xsl will not result in any information being returned. 
This includes, by default, the configuration information for

      * disable-print-link
      * disable-pdf-link
      * disable-xml-link
      * toc/@location
      * disable-external-link-image
      * obfuscate-mail-links

This is because the aggregation of the skinconf happens at the pipeline
matching "*.html".  This pipeline aggregates skinconf.xml, tab-*, menu-*
and body-*.

The items above (disable-*-link, etc) are handled in the pipeline for
body-* by the document2html.xsl transformation sheet.  That pipeline
does NOT have access to the skinconf at this point.  It would if the
aggregation was done in the "body-*" pipeline.

There are a couple of ways of solving this:

     1. Move the aggregation to the body-* pipeline.  The "*.html" will
        then also have access to the skinconf.  However, if this is
        done, it should probably be done for the tab-* and menu-*
        pipelines as well.  Currently, it doesn't look like these last
        two pipelines make use of anything in the skinconf, but that may
        not always be the case.  Not too fond of this one.
     2. Move the skinning bits out of document2html and handle it all
        within the "skinit" resource.  This may require putting place
        holder tags in the html generated by document2html that "skinit"
        can then replace with proper skinconf values.  I like this
        option better than #1.
     3. Go back to using document().  Don't like this option either.

Thoughts?  Any other options?  More explanation required?  BTW, I'm
seeing this on the copyless branch.

Rick Tessner <>

View raw message