Lists Home |
Date Index |
On 6/24/05, James Adams <email@example.com> wrote:
> James Fuller wrote:
> >u do not *have* to place all your xsl into one huge xslt
> >why not bring in each seperate XSLT using xsl:include?
> >then use modes to disambiguate between matching 'xsl:template' templates.
> >gl, Jim Fuller
> That would work, but it would likely cause some naming issues with the
> modes. The problem is that for each web application there is one Site
> object (or in this case XML file) which has sometimes hundreds of
> Modules, which in turn have anywhere from 20-50 views. On each HTTP
> request the framework loads one Site, one Module, and one View, but
> which one it loads is determined dynamically by information extracted
> from the request. Although I always try to use unique names for views,
> it is possible that there are Views in different Modules that have the
> same name. Is there a way to get around this by using xsl:key
> assignment? I haven't had much luck in getting that kind of thing to
> work properly, but if you have any suggestions I would love to hear them.
This may be overkill for your purposes, but you may want to look at a
pipelining solutions such as Cocoon (or similar). With such tools, an
input configuration XML can drive one XSLT which then in turn goes off
and grabs the appropriate data and/or runs the appropriate XSLT to do
the actual work.
In our case, we're completely meta data driven and as such we use
Cocoon to do things like building dynamic XSLT (ie, using another
configured XSLT) which are then used to transform other XML (or
validate responses via Schematron in our case).
In your case, simply placing the SITE/MODULE/VIEW definitions in
appropriate directories and subdirectories and using successive XSLT
to grab each in turn based on directory path parameters built in, or
passed from, the previous transform should work without all the Cocoon
machinery if the specific transforms are static and only the input