Rick Tessner wrote:
> 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-*.
Good catch!
> 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.
Right, excellent ananysis.
> 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.
This is a good suggestion.
We have sort-of seen how having different xsls for the page parts is
usually more an issue than a feature, so it may be that we will move to
a single xsl file, and keep the current decomposition using imports in
the xsls.
> 3. Go back to using document(). Don't like this option either.
>
> Thoughts? Any other options? More explanation required?
This is the clearest and most detailed bug report I've seen in months :-)
> BTW, I'm
> seeing this on the copyless branch.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
|