RE: [xsl] XSLT 2.0 question

["Bryan Rasmussen" <bry@xxxxxxxxxx>]

thanks, Jeni already got me to re-consider my bad design and have the
application do the handling, have a workable solution mapped out. Still wish
it could be from some future xslt version(since this functionality should
most probably be in a future version of the app.)
-----Original Message-----
From: owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx
[mailto:owner-xsl-list@xxxxxxxxxxxxxxxxxxxxxx]On Behalf Of Robert Koberg
Sent: 18. marts 2002 14:02
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] XSLT 2.0 question


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



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list