Kjetil Kjernsmo wrote:

Dear all,

There is an abundance of XSLT resources on the net and in books that discuss the details of XSLT, but yet, I feel I'm struggling to get things right...


We've all been there before. XSLT turns conventional procedural programming on its head, and it can often be difficult to relinquish control to the XSLT transformation engine, and trust it to just do "The Right Thing(tm)".


I'm by no means an expert (any experts here?) but I find my method works well for what I use it for. Keep in mind that I only ever develop sites in English, so for information on multi-lingual sites, you may want to dig a bit deeper.

Usually, I design content to be rendered to multiple output types (e.g. pretty XHTML, printable XHTML, PDF, raw source, etc). I utilize <xsl:import/> to merge common functionality, rather than the AxKit pipeline, except in situations where my source XML needs to be scrubbed prior to display processing (e.g. to merge multiple XML files, pre-sort data, etc).

Here is some sample code from the site I'm working on now. I've trimmed it down for brevity.

<AxStyleName "#default">
   AxAddRootProcessor text/xsl /stylesheets/object-xhtml.xsl object
</AxStyleName>
<AxStyleName "print">
   AxAddRootProcessor text/xsl /stylesheets/object-print.xsl object
</AxStyleName>

Here I have two stylesheets that match for the same root element, in different AxStyleNames. In the "object-xhtml.xsl" file, I have:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
<xsl:import href="common.xsl"/>
<xsl:import href="object.xsl"/>
<xsl:import href="design-xhtml.xsl"/>
</xsl:stylesheet>


"common.xsl" defines common EXSLT functions, templates, etc. "object.xsl" processes the actual document data, and finally the "design-xhtml.xsl" stylesheet overrides any other templates for rendering with the site's pretty XHTML look & feel. The only difference between this file and "object-print.xsl" is the last import statement loads "design-print.xsl". This file also gives you the opportunity to override any templates within your standard "object.xsl" file, so as to customize how something will look within a given output style.

Each of the design-*.xsl stylesheets outputs XHTML that includes either design-xhtml.css or design-print.css for the page's cascading stylesheets. Each of them includes as the first line:

@import url("common.css");

so I can have common site styles, with each AxStyleName possessing it's own custom style rules for each output type.

Finally, I define a style name for outputting the source XML verbatim, with the exception of a little scrubbing:

<AxStyleName "raw">
   AxAddProcessor text/xsl /stylesheets/raw.xsl
</AxStyleName>

this way, if I need to, I can do an <xsl:apply-templates select="document('filename?style=raw')"/> if I need to merge data from other data sources. For instance, I have a glossary.xml file that defines words so, within any document, I can wrap a given piece of text with <glossary></glossary> to, if present in the glossary.xml file, create a tool-tip definition for that word. (Note: There's probably a better way of handling this; anyone?)

If you want to see this in action check out http://aom.nachbaur.com/ (its in CVS at http://cvs.nachbaur.com/cgi-bin/viewcvs.cgi/MozillaAOMReference/ if you want to take a look at how I build the source, but be warned: its still in active development).

I have data flowing from several different sources: The same document fragment may come from a Provider, or from some XSP. Also, my basic idea is that many things should be included by XSLT. For example, I have had the idea that stuff that are common for for the entire site, such as headers, menus and the like, should be imported by an XSLT by for example an axkit: URI. Also, since my own language is spoken by only 4 millon people, I'm going multi-lingual from the start, and I figured I want a separate page with phrases, so that languages can be added by simply have someone translate a single file.


How you architect your stylesheets really depends on how the data is structured, how the page will be structured, etc. For instance, I find the above design pattern works well for the sorts of sites I build, but there are instances where I use the AxKit pipeline instead to output to plain-and-ugly XHTML, and then further style it with additional stylesheets.


So, how do you folks designing this stuff, and do you know some good resources that deals with things like this rather than the details?



I too would be interested to see how other people design their sites. There's always something you can learn from someone else's design patterns. My method more-or-less congealed, and I'm sure there are some sticking points that I've run across that could be mitigated if I just found out another way to do it.


Perhaps the [EMAIL PROTECTED] would be a better place to discuss this, but I feel that people here are always so nice and helpful, and besides, it is in connection with AxKit that I'm wondering.

I'm sorry I haven't replied earlier than this, but between work and the aforementioned site, I've been stuck on my little hamster-wheel. :-)

Cheers!

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to