This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: 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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]