You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@forrest.apache.org by "J.Pietschmann" <j3...@yahoo.de> on 2002/07/20 12:06:24 UTC

String replacements on skin XSLT

Hi,
I noted already in another post that currently there
are string replacements made by ant/whatever on the
skin document2html.xsl. This is a dangerous operation
due to encoding issues.

Let's restate the kind of description files we
already have:
  - content
  - book.xml, one per directory: sort of local navigation
    *on web pages*
  - tab.xml, one per project: sort of global navigation
    on web pages
  - string replacements in buildfile, one per project
    (I hope): provide breadcrumbs to get the project
    in an even higher context (in case of the FOP
    project Apache -> Apache XML -> FOP
  - hardcoded in xhtml2site "Search Apache XML" and perhaps
    other stuff

Ok, describing local navigation (per directory) and project
global navigation appears to be solved (though "book.xml"
is a misleading name now).
What do we still need:
- a description how the project embeds in a higher context
- a description for online search facilities

For FOP, I used an unimaginatively named "project.xml" for
the first and left the latter alone (hardcoded in the skin
XSLT)
Any Ideas how to improve this?
Should the project embedding hierachy description
- get a new file
- go into tab.xml
- go into forrest.xgump (or whatever is currently in fashion)
Then there is also the question how to build printed books
(read: PDFs with FOP). I'm not sure how much of the navigation
stuff can be reused for this.

Another question which bothers me: why is there an xhtml2site.xsl?
I'd rather have the local, global, project hierarchy and search
description aggregated with the content (in document DTD) and
transform it all together in one step into HTML. Much more robust
against changes (you don't depend on <div> classes), and easier
to mix stuff if necessary (for example you can have navigation
links between sections if you feel this is a good idea).
(No, caching and performance are not arguments for the current
architecture as long as you use the copy-through template
rather than copy-of for copying the pretransformed XTHML in
the final xhtml2site).

Last questions: standard diretory structure and file places:
- Where should the global navigation file (menu.xml) live?
   I'm not sure whether the top level doc directory is the
   right place. But then, it may be.
- where should the skin go?
- Where to put images? Toghether with the docs in the same
   directory, a subdirectory of the directory where the doc is,
   or a single directory which is a subdirectory of the top
   level doc directory? The problem here is the Cocoon mapping
   which appears to force the latter, and that the skin needs
   "shared images". I'd favor to put shared images (for both
   the skin and the docs) into a image subdir of the top-level
   doc dir and everything else local, and have always a proper
   relative path to the image in the final HTML  so that Cocoon
   does not need to map this. For the skin, this means the XSLT
   must be aware of the directory depth (relative to top level).

J.Pietschmann