Why do you have the xsl:output tag in the JSP? Shouldn't it be in the XSL-document?

/Niklas
-----Ursprungligt meddelande-----
Från: Jeff Chapman <[EMAIL PROTECTED]>
Till: Orion-Interest <[EMAIL PROTECTED]>
Datum: den 19 januari 2001 19:11
Ämne: Having trouble forcing browser-side XSL transformations


>Hi Folks,
>
>Although I'm an experienced Java and Web 
>developer, I'm very new to Orion and am 
>trying a tactic that I've seldom seen 
>mentioned on this newsgroup.  My search 
>of posts for the last few months shows one 
>person doing something pretty similar, but 
>recommendations to his note haven't solved 
>my problem.
>
>Basically, I would like a JB to emit pure XML
>into a JSP which wraps it in the proper code
>to cause IEv5.5 to perform the XML/XSL 
>transformation (instead of the server).  I've 
>been able to get this logic to work in other 
>web crafting environments (Tango and ASP), but 
>have not been able to get it to work from JSPs.
>
>I've got a local JB (ClassInfoBean2.java) 
>with a method that emits a chunk of XML.  
>The following code is in the associated JSP.
>
>[NOTE: The <xsl:output...> lines were the 
>recommendation I found in a note from 
>1/8/01 who's subject is "XSL on Orion 
>returns content type text/xml instead 
>of text/html".  Whether these lines
>are present or not has made no difference.]
>
>This JSP code is about as simple as 
>it gets.
>
>  <?xml version="1.0"?>
>  <?xml-stylesheet type="text/xsl" 
>    href="ClassInfo2.xsl"?>
>  
>  <xsl:output method = "html" 
>   indent = "yes" 
>   doctype-system = "http://www.w3.org/DTD/HTML4-strict-dtd"
>   doctype-public = "-//W3C//DTD HTML 4.0//EN"
>   media-type= "text/html" />
>  
>  <jsp:useBean id="ClassInfoBeanId" 
>    scope="session" 
>    class="school.ClassInfoBean2" />
>  <jsp:setProperty 
>    name="ClassInfoBeanId" property="*" />
>  
>  <root>
>    <jsp:getProperty 
>      name="ClassInfoBeanId" 
>      property="xmlData" />
>  </root>
>
>The associated XSL file is too long to try 
>to post in this note.  The content probably
>isn't a part of the problem since the browser
>doesn't even try to do the transformation.  
>When I copy the following XML into an XML file,
>the browser loads the file and performs the
>transformation perfectly.  However the browser
>refuses to perform the transformation when
>the same XML is emitted from a JSP file.
>
>Here's the XML output that the JSP emits:
>
>  <?xml version="1.0"?>
>  <?xml-stylesheet type="text/xsl" 
>    href="ClassInfo2.xsl"?>
>  <xsl:output method = "html" 
>    indent = "yes" 
>    doctype-system = "http://www.w3.org/DTD/HTML4-strict-dtd"
>    doctype-public = "-//W3C//DTD HTML 4.0//EN"
>    media-type= "text/html" />
>  <root>
>    <title>Class Info</title>
>    <stylesheet>resources.css</stylesheet>
>    <studentinfo>
>      <id>234567890</id>
>    </studentinfo>
>    <class>
>      <id>23</id>
>      <name>ThisName</name>
>      <descr>Relatively longggg Description</descr>
>      <section>ThisSection</section>
>      <dept>ThisDept</dept>
>      <maxsize>18</maxsize>
>      <credits>3</credits>
>      <startdate>1-18-2001</startdate>
>      <starttime>13:00</starttime>
>      <finishtime>15:30</finishtime>
>      <building>thisBuilding</building>
>      <room>thisRoom</room>
>    </class>
>  </root>
>
>Now when this is sent to IEv5 (with the latest
>XSLT updates installed), the XSL file should be 
>loaded and used to transform the XML data into
>the appropriate HTML--but this is not happening
>and I can't tell what's missing.
>
>Specifically, I can't tell if the browser isn't 
>able to find the XSL file (thus the subject 
>of this note), or if the browser doesn't know 
>that this is really an XML page that warrants 
>XML/XSL processing, or if the browser thinks 
>there's a valid reason (ie., security) to avoid 
>doing the transformation.  No errors are 
>produced, the browser simply refuses to do 
>the transformation.
>
>In this setting, I have several questions.
>
>1.  Given the <?xml-stylesheet...> statement
>shown above, where should I put the XSL file?
>Perhaps with the JSP files? (This worked for the 
>CSS files in this project.)  Perhaps a different
>path in the href value would be appropriate?
>Any suggestions?
>
>2.  Do I need to explicitly tell Orion to 
>handle XSL and/or CSS file types?  There
>wouldn't be much for Orion to do except emit 
>their contents 'as is' and let the downstream 
>device do the processing.  If I don't do this 
>then it would seem that these files would be 
>(apparently) served from a different server 
>(http://whatever:8080/something vs 
>http://whatever/something).  I mention this
>because it occurred to me that the browser's
>sandbox might be interfering with loading the 
>XSL file from what appears to be a different 
>domain that where the original page is served 
>from.  My gut feeling is that this shouldn't 
>be necessary, but I don't want to leave any 
>stone unturned in this search.
>
>3.  There's a possibility that the browser is
>confused since the URL ends in JSP but I'm 
>returning XML content.  That is, the browser may
>not realize that it is appropriate for it to 
>do the XSL transformation.  The first two lines 
>should remove any of the browser's doubt about the
>content type of the page, but since nothing I've 
>done has made a difference I don't want to rule 
>this out as a possible cause of confusion.
>
>My plan is to produce a transform object 
>which detects the browser's capabilities and 
>pushes the transformation as close to the 
>browser as possible.  In the case of IE5, 
>then we would emit XML with an appropriate
>reference to a transformation file.  In browsers 
>that don't handle XML but have a JRE, we would 
>emit a page with a reference to a compiled 
>transformation (produced by Sun's XSLT compiler).
>If the browser has no XML nor JRE support,
>then the Server will perform the transformation
>and emit HTML.  The ultimate goal is to maximize
>the utilization of the browser's capabilities.
>
>Anyone had any luck getting IEv5 to participate 
>in this tactic from a JSP page?  Any suggestions 
>would be appreciated.
>
>Cheers,
>Jeff Chapman
>Pervasive Software
>


Reply via email to