This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT 2.0 question
- From: Robert Koberg <rob at koberg dot com>
- To: xsl-list at lists dot mulberrytech dot com
- Date: Mon, 18 Mar 2002 05:02:20 -0800
- Subject: Re: [xsl] XSLT 2.0 question
- References: <DCEPIHHFOCEMDBGBKIOPAECPCFAA.bry@itnisk.com>
- Reply-to: xsl-list at lists dot mulberrytech dot com
Hi,
Bryan Rasmussen wrote:
>>You seem to be defeating the purpose of separating your content from
>>your presentation (that is why we like XSLT, right?). This app sounds
>>like it needs to be redesigned... If your app cannot take more than one
>>*primary* XSLT, I would say it is pretty limited. But, I may be
>>misunderstanding what you wrote...
>>
>
>the app can take lots of xslt's, but users are locked into our xslt's,
>although I've created some specific ways for users to control the
>transformation output by describing output requirements in metadata files
>there is still a level of lock-in, I was just hoping to allow users to
>overwrite templates using embedded stylesheets.
>
we have an app that does something like what you are describing(in a
J2EE servlet container). The directory structure is similar to :
- approot (master)
|
|-- site1
| |
| |-WEB-INF
| |
| |-xsl
| |-content
| |-classes
|
|-- site2
| |
| |-WEB-INF
| |
| |-xsl
| |-content
| |-classes
|
|- WEB-INF
|
|-xsl
|-content
|-classes
You can have a flag attribute in a config file that tells you to use the
'master' XSL(T) or the site's. The sites can have shells or wrappers in
the their /WEB-INF/xsl folder that use as many of the 'master' component
templates they like, or none (as you may know, everything under WEB-INF
is protected in a J2EE servlet container). What is nice about this is
you have one virtual host for the app and virtual hosts for each site.
At an appropriate time, the user generates as much static content as
possible (including JSP's, whatever...) to the docroot of the particular
site when they want. Then you can have a QA type of thing when the user
hits their site's virtual host, while still being able to work
dynamically on the app's virtual host. Once Qa'd copy the site to the
live server.
maybe this can help?
best,
-Rob
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list