Hey Maurice,
        Thats exactly what I'm working with now. And most examples seem to
follow that pattern. However, I do not want to have physical file mappings
for the XSL files (eg. No actual .xsl files).
        So where we have today:
                <?xml-stylesheet href="hello.xsl" type="text/xsl"?>
        refering to a physical file called hello.xsl. What would be more
flexible would be an XSL definition that sits in a database.
        We could, thereby, dynamically select the xsl to display:
                <?xml-stylesheet href="xslfactory()" type="text/xsl"?>
        The benefit of this approach would be that if a new technology comes
out or and old technology changes, an xsl definition of could be
inserted/updated to a database without having to change any physical files.
        Basically, most J2EE web applications are deployed via WAR/JAR/EAR
files that are physically moved to a server. Therefore, XSL file definitions
are also contained within those archives. That means that any
changes/additions will require a person to go in and expand those archives.
Add the files. Redeploy the archives. That doesnt sound like much. But for
those of us who have had to deal with Change control procedure *shudder*. A
simple change like that could take weeks. IF there were NO physical XSL
definitions, however, we would not have to worry about all that as well as
all that could go wrong in those steps (change control messing up a file,
corrupt transfer of archives, etc..)
-Tim

-----Original Message-----
From: King Maurice [mailto:[EMAIL PROTECTED]]
Sent: Friday, November 09, 2001 1:31 PM
To: [EMAIL PROTECTED]
Subject: Re: XML and Java

What about next generation net enable browser-devices

Their presentation layer is different and image contraints are also factors.

I like your point on display data based on what was passed.

Maybe have a mechanism to call the xsl file based on device type and then
display data regarding to what was passed.

XLS
---
-IE 6.0 [call  IE_HomePage.xsl]
 -> [call IE_LoginPage.xsl]
 -> [call IE_DisplayUser.xsl]

-PDA [call  PDA_HomePage.xsl]
 -> [call PDA_LoginPage.xsl]
 -> [call PDA_DisplayUser.xsl]

-WAP [call  WAP_HomePage.xsl]
 -> [call WAP_LoginPage.xsl]
 -> [call WAP_DisplayUser.xsl]

This may required more work but at least you separate your functions from
the (device/browser)presentation layer and component(homepage, login
page)presentation layers.

This way once a new device comes out you'll code for that devices's medium.
or a customized extranet-intranet browser that you developement team created
with your business partners.

You will be able to hit all mediums bascily.

Maurice~
[EMAIL PROTECTED]

>Hey Margaret,
>        Thanks for the response. I was, however, just wondering about
>something that you kind of touched on. You mentioned that.. "However, you
>would not really want to generate your XSL dynamically because you want the
>results to be consistent". Actually that is exactly what I want to be
>dynamic :) I was thinking of having a XSL factory class that would show
>different results/displays depending on what XML data was being processed.
>That would eliminate the need to have physical XSL files for my deployment
>as well as give me the option of loading things dynamically so that if
>someone decides to change a display.. i can make changes via some type of
>control tool (maybe via database settings) without having to edit physical
>files and redeploy the application.
>        Does that make sense? I just got back from lunch and until the
>blood
>comes back from my stomach to my head.. I might be a bit incoherent. :)
>-Tim

===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff
JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST
DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:

 http://archives.java.sun.com/jsp-interest.html
 http://java.sun.com/products/jsp/faq.html
 http://www.esperanto.org.nz/jsp/jspfaq.jsp
 http://www.jguru.com/faq/index.jsp
 http://www.jspinsider.com

===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:

 http://archives.java.sun.com/jsp-interest.html
 http://java.sun.com/products/jsp/faq.html
 http://www.esperanto.org.nz/jsp/jspfaq.jsp
 http://www.jguru.com/faq/index.jsp
 http://www.jspinsider.com

Reply via email to