Discussions

Web tier: servlets, JSP, Web frameworks: JSP emitting XML/XSL to IEv5

  1. JSP emitting XML/XSL to IEv5 (31 messages)

    Hi Folks,

    Although I'm an experienced Java and Web developer, but I'm trying a tactic that I've seldom seen mentioned in JSP newsgroups.

    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 in the Orion newsgroup 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 in solving my problem.]

    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 or Tomcat 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

    Jeff dot Chapman at pervasive dot com
    Pervasive Software

    Threaded Messages (31)

  2. JSP emitting XML/XSL to IEv5[ Go to top ]

    Jeff,

      I must admit that I have not read through your entire post. Taking a cursory look at the JSP it appears that the page directive that sets the content type is missing (or maybe I did'nt catch it...).

      Try setting the page attribute as follows:

      <?xml version="1.0"?>
      <!DOCTYPE .............. >
      <%@ page contentType="text/xml" %>

       .....
       .....

      I believe that without the contentType being set as a "Page Directive" IE has no way of knowing what is coming at it is XML. It probably assumes whatever is the default type. If I had the time, I would test this theory out.

    Hope this helps.

    Raj
  3. JSP emitting XML/XSL to IEv5[ Go to top ]

    Jeff-

    Great post! I have to concur with Raj here. I didn't read through the entire posting, because my first gut instinct was that the content type was never correctly set. I think you have done everything else correctly (but I've never tried to send pure XML to the browser before).

    Also, if you were to do this in a servlet instead, one of the first methods you call is response.setContentType(...) which is the equivalent of doing the <%@ page contentType= %> that Raj mentions. If you do not do this, the default content type is test/html.

    Tyler
  4. JSP emitting XML/XSL to IEv5[ Go to top ]

    hello everybody,

    IE Browser 5.0 and above automatically takes your response as HTML even if not specified. Unless explicitly specified your output cannot be an XML.

    However, the netscape requires your response to be explicitly to be mentioned. Yes , it is a good idea to mention your response always.

    If you have mentioned your response to be res.setContenttype ( as xml) , then it will send and xml output as well please mention the version as 1.0 as required.
    otherwise I am not able to see anything immediate. However, please send ur code to my email address at
    bp8475 at sbc dot com.Let me try to run it using the Xalan parser that I have.

    Prasath .

    I can also send some references where you can see details for all these
  5. JSP emitting XML/XSL to IEv5[ Go to top ]

    Hi:
    I am a direct recruiter for a company in Seattle looking for senior level java developers with weblogic experience.

    The compensation is at the top of the scale and it is a terrifice project.

    Do you know anyone that might be interested?

    Thanks very much for your consideration.

    Karen
  6. Hello Karen!
    I am looking for an intership for this summer!
    I am doing my masters at K-State univ majoring in CS.

    I have done enough projects in java to be called as experienced java programmer.

    Are there any internships openings in your company?
    Thank you!
    With regards
    Madhu Tera
  7. Hi
        I am Deepak Bhatt, working as a java developer in Frankfurt(Germany) with 2.8 year experience in java,servlet,JSP,Ejb and worked on the application server like Weblogic version 5.1 if you have a suitable vaccancy in your company do let me know
    My mailId= bhattdeepak75 at hotmail dot com

    Regards
    Deepak
  8. JSP emitting XML/XSL to IEv5[ Go to top ]

    Hi,

    May be informative:
    http://www.w3.org/TR/xslt#section-Embedding-Stylesheets.

    You can also try Microsoft's XML Islands.

    Thanks
    John
  9. JSP emitting XML/XSL to IEv5[ Go to top ]

    As per the stylesheet, you might want to specify the URL (not URI) for the browser to find it.

    Miroslav,
    Principal Consultant
    Oracle Corp.
  10. JSP emitting XML/XSL to IEv5[ Go to top ]

    Thanks to all the suggestions to this puzzle.

    The suggestion to add the contentType did the trick.

    <%@ page language="java" contentType="text/xml" %>

    I also got an email from Anders Dahlberg suggesting an alternative way of doing the contentType as shown below:

    <% response.setContentType("text/xml"); %>

    Both of these suggestions solved this problem.

    At this point, I've gotten all of the basic mechanisms working and am well on my way to meeting the goals I mentioned in my original note. When I've gotten it all working, I'll post more info on how well it works (and more importantly, how well it seems to scale).

    Thanks again,
    Jeff
  11. JSP emitting XML/XSL to IEv5[ Go to top ]

    Jeff,

       I am very interested in knowing your findings. Up until recently, only IE5 had built in capabilities to deal with XML. Is your user base fixed on using IE5?. In many of the projects that I have been involved in we had to support 4th generation browsers (NS4+, IE4+). There were also other browsers like AOL's that also had to be supported.

       The approach of XML/XSL transformation on the client side works only if you know that the client browser is capable of it. Aside from that, the onus of transforming the data is on the client processor. What volume of data does your XML encapsulate. What if the situation warrants that the XML (after it has been transformed) has to be presented in several pages?.
  12. JSP emitting XML/XSL to IEv5[ Go to top ]

    Well, my user base is not fixed on using IE5. Instead they are fixed on using everything from IE through WebTV as well as handheld devices (eg., PDAs and Cell Phones) and nearly any networked appliances.

    My goal is separate the various layers so different team members can specialize in a reasonable number of different technologies. The guys who know how to get the right data out of the repositories are not colliding with the business logic guys nearly as often as they do today; the guys who know how to work with the downstream device's presentation capabilities aren't colliding with the business logic or database folks either. Right now, I've got a team that are forced to be 'jacks of all trades' instead of being our company gurus in particular disciplines.

    So the backend focuses only on accumulating the data through JB/JDBC or EJBs which is then fed to the JSPs. The JSPs only worry about filtering/reducing the data as needed for the detected downstream device. XSLTs are used to control all formatting and layout issues while CSS is used for the purely cosmetic stuff. Using BrowserHawk/J by CyScape, the JSP also determines the capabilities of the downstream device--which determines which stylesheets to utilize.

    If that device is IE5 (with the latest XML update), then we only have to ship an XML file with a reference to an XSL transformation. If that device can do the transformation in their JRE, then we'll ship them an appropriate XSLTc precompiled transformation along with the raw XML data so they can do the transformation themselves. If JRE/XSLT capabilities are totally lacking in the client, then the server will do the transformation and emit the HTML directly to the browser--but this is a last resort.

    As far as the volume of XML data that gets moved over the wire, one of the tasks of the JSPs (along with the BrowserHawk/J objects) is to reduce the data to the minimum that the stylesheet will require.

    The overall goal is to utilize the downstream client as much as possible to lighten the load on the servers.

    You might be surprised to find that an HTML page that contains a huge table with lots of rows and columns takes about 20 times longer to download and render as HTML than sending the equivalent XML data with an XSL stylesheet and letting the browser do the rendering. The performance I'm measuring is the time beginning with pressing 'Refresh' until the page is completely downloaded and rendered.

    I was stunned the first time I saw the performance differences. In retrospect, it makes sense. There's is usually less data to transmit over the wire (comparing the number of bytes of HTML data vs the XML/XSL data that can generate the same HTML screen). As mentioned above, HTML tables are terribly expensive to render in the browser (especially if they are not fixed-size tables) whereas an XML/XSL transformation is an order of magnitude faster to render in the same browser.

    Anyway to return to your original point, my motivation is that my customers typically are trying to screw a wide variety of different clients onto their existing traditional Client/Server applications. This includes clients written in C/C++ and VB/Delphi as well as using any HTML capable device as a client.

    So my basic requirement is to provide an infrastructure to simplify and optimize our development efforts as we screw New Age Clients onto these aging, and often antique, Client/Server apps.

    Cheers,
    Jeff
  13. JSP emitting XML/XSL to IEv5[ Go to top ]

    Jeff,

       Appreciate you sharing a lot of background information.

    You wrote:

    > You might be surprised to find that an HTML page that
    > contains a huge table with lots of rows and columns takes
    > about 20 times longer to download and render as HTML than
    > sending the equivalent XML data with an XSL stylesheet
    > and letting the browser do the rendering. The performance
    > I'm measuring is the time beginning with pressing'Refresh'
    > until the page is completely downloaded and rendered.

    That was something that I did'nt know and frankly would'nt have suspected. Useful bit of information to know.

    Thanks
  14. JSP emitting XML/XSL to IEv5[ Go to top ]

    Here's a bit more info on a complication associated with this tactic. In particular, with each page refresh, I was getting lots of Socket Write Errors. There are lots of reasons for these errors--some of them are self-inflicted and others are simply unavoidable.

    It is normal for a browser to abruptly close an existing connection to a server if the user reloads the page, or if the user presses the Stop button during a download. This will usually case a socket write error resulting in a lengthy stacktrace being dumped to the app server's log file.

    But I was getting this error as many as four times per refresh in my original architecture and I had what appeared to be a massive memory leak in my AppServer. I also found that this same problem existed regardless of which AppServer I tried (which included Tomcat, JRun and Orion).

    Last weekend, I found that the source of my problem was purely IE5 and XML. I cobbled a way to test this with Netscape and this problem does not happen at all.

    As mentioned in earlier posts, I'm basically using JSPs to generate pure XML pages with references to XSL stylesheets so that IE5 can do the transformations (instead of using server resources). In the following description, I don't mean to suggest that I've debugged into IE5 and understand how the IE5 engine actually works--rather I'm describing what seems to be the behavior.

    Here's the scenario. You're looking at a web page with a link to a JSP. When you click this link, the browser requests the JSP page. This JSP emits a page directive to change the contentType to "text/xml". It seems that as soon as IE5 gets this contentType switch, it abruptly drops the existing connection to the server and immediately requests the same page again.

    Well, this can cause problems on the server. For example, if the JSP page takes a non-trivial amount of time to render itself, then the socket write error will almost always occur since the 'peer' (IE5 in the case) always abruptly terminates the first connection to start the second. If the first JSP page request had time to open a database connection (before the second page request yanked the rug), then the socket write error may also interrupt the JSP's ability to execute enough logic to get to close the database connection at the bottom of the page. This tends to leave database connections hanging until they timeout.

    In my case, I was using a frameset which contained four JSPs--each of which emitted XML. In this case, each time I pressed F5, I saw four complete sets of "Socket Write Error" tracedumps along with stranding four different database connections. Imagine this problem in a scenario where hundreds or even thousands of customers were requesting updates to this frameset. There are two painpoints. First is the penalty of forcing the server to deal with needless exception handling four times per reload action (a performance penalty associated with dumping the stacktrace to the log file). Second are the resources held in limbo by stranded database connections (which looks like a big memory leak).

    My workaround is to avoid sending a pure XML page to IE5. Instead I send the XML data in an XML data island and use JavaScript to do the transformation. [Sample code follows] IE5 is still doing the transformation but since we're sending a real HTML file with embedded XML, instead of a real XML file, we don't have IE5 requesting every page twice.

    I would prefer to be sending pure XML/XSL to the browsers that can handle it. But even when/if this problem is fixed by MS, we still have to accommodate the millions of IE5 installations that don't have the patch. So this workaround is likely to stay online for a long time in my apps.

    I guess you could say that instead of fixing the problem, I'm avoiding the situation that leads to the problem in the first place.

    Cheers,
    Jeff

    <HTML>
    <HEAD>
    <XML id="xslTransform" src="http://<%=request.getServerName()%>/Whatever/Style/ClassData.xsl">>
    <XML id="xmlData">
    <root>
    <!-- This JSP file emits the pure XML data for this page -->
    <jsp:include page="ClassData.jsp" flush="true" />
    </root>
    </XML>
    <script language="JavaScript">
    function doInitPage()
    {
      oData = xmlData.XMLDocument;
      document.all("InsertHere").innerHTML =
        oData.transformNode(xslTransform.XMLDocument);
    }
    </script>
    <link REL="STYLESHEET" TYPE="text/css"
      HREF="http://<%=request.getServerName()%>/Whatever/Style/ClassResources.css" />
    </HEAD>
    <body onload="doInitPage()" CLASS="NormalText" bgcolor="white" topmargin="0" bottommargin="0" leftmargin="0" rightmargin="0">
    <SPAN ID="InsertHere"></SPAN>
    </BODY>
    </HTML>

    Another variation is to have the JS actually replace the entire BODY section of the page. This would let the XSL file have complete control over the attributes of the Body tag. In my case, this wasn't necessary.
  15. JSP emitting XML/XSL to IEv5[ Go to top ]

    Jeff,

       You may find the following of interest to you:

    ESPX - an ECMAScript Parser for (almost) XML
    TinyXSL - XML transform in-Script mini-Language

    Both of these are for web user agents without built-in XML support.

    http://cjandia.freehomepage.com/me/works/xml/espx/20010129.089/espx.htm

    Regards

    Raj
  16. JSP emitting XML/XSL to IEv5[ Go to top ]

    You can have something like this, also:


    <script>
    var xmlDom = new ActiveXObject("Microsoft.XMLDOM");
    var ss = new ActiveXObject("Microsoft.XMLDOM");
    xmlDom.async = false;
    ss.async = false;
    xmlDom.load("./jsps/dataAsXML.jsp");
    ss.load("./ui/styles/theStyle.xsl");
    document.write(xmlDom.transformNode(ss));
    </script>
  17. For this you can use one of the many XSL apply body tags that are arround. The XLM is the body content for your custom tag and it's attribute points to a stylesheet.
  18. how about the script writing on the server side which can be browser by any kind of the browsers, thanks?
  19. <script>
    var xmlDom = new ActiveXObject("Microsoft.XMLDOM");
    var ss = new ActiveXObject("Microsoft.XMLDOM");
    xmlDom.async = false;
    ss.async = false;
    xmlDom.load("./jsps/dataAsXML.jsp");
    ss.load("./ui/styles/theStyle.xsl");
    document.write(xmlDom.transformNode(ss));
    </script>

    would anyone tell me how it can be written on the server side, thanks?
  20. JSP emitting XML/XSL to IEv5[ Go to top ]

    Jeff:

    i have tried to run the xml file and saved it a .jsp file
    but instead i have changed the xsl style sheet in the .xsl file as:
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">

    this perfectly worked without setting contentType as "text/html" or "text/xml"
    and i tried putting both content types and it coolely worked for either html or xml in the jsp.


    Vijay
  21. sir,
    pls help me in embedding xml into jsp as i know some xml and good knowledge in jsp.pls try to give me some small examples in that.
    thanking you

    yours scincerely
    venkat
  22. Hi venkat,
    The test.jsp file is :


    <?xml version="1.0"?>
    <?xml-stylesheet type="text/xsl" href="test.xsl"?>
    <root>
    <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>

    The test.xsl file is:

    <?xml version="1.0" encoding="UTF-8"?>
    <!--<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fo="http://www.w3.org/1999/XSL/Format">-->
    <xsl:stylesheet xmlns:xsl="http://www.w3.org/TR/WD-xsl">

    <xsl:template match="/">
      <html>
      <body>
        <table border="2" bgcolor="yellow">
          <tr>
            <td>Student ID:</td>
    <td>
    <xsl:value-of select="root/studentinfo/id"/>
    </td>
    </tr>
        </table>
        <font face="arial">Class :</font><br/>
        ID: <xsl:value-of select="root/class/id"/><br/>
        Name: <xsl:value-of select="root/class/name"/><br/>
        Max Size: <xsl:value-of select="root/class/maxsize"/><br/>
      </body>
      </html>
    </xsl:template>
    </xsl:stylesheet>

    Save these two files in the public_html folder of the Javawebserver2.0 and run the .jsp file and u can see the result.

    Vijay
  23. JSP emitting XML/XSL to IEv5[ Go to top ]

    I have tried using the sample files (test.xsl and test.jsp) but I can't get IE to perform the transform. After I add the line to set the content type to text/xml, IE recognizes that it is an XML document (if you view File | Properties), but it still renders it as an HTML file (the long string with all of the data appended).

    I tried the few things that I saw in this thread:

    - <%@ page language="java" contentType="text/xml" %>
    - <% response.setContentType("text/xml"); %>

    But with no effect, here is all that I see once the page gets to IE:

    - 234567890 23--xx ThisName Relatively longggg Description ThisSection ThisDept 18 3 1-18-2001 13:00 15:30 thisBuilding thisRoom

    If I view the source and save it as an XML file, then open the file directly in IE it transforms it correctly. I'm stumped - any thoughts?

    Thanks in advance,
    Ted
  24. JSP emitting XML/XSL to IEv5[ Go to top ]

    Sorry to take so long to get back to this thread of discussion.

    Are you sure that your IE5 installation has the updated XML/XSL objects? Fully functional XSL transformations require that most IE5 installations go to the MS website to download the latest updates to the MSXML Parsers (I believe the last release was last fall, around September, and is called version 3.0).

    If you don't have these updates, then you'll have the problem you described above.

    Cheers,
    Jeff
  25. JSP emitting XML/XSL to IEv5[ Go to top ]

    That worked - thanks for the info. Upgrading the XML Parser to MSXML 3.0 did the trick, its now performing the transform and rendering the HTML after applying the stylesheet.

    Thanks again,
    Ted
  26. JSP emitting XML/XSL to IEv5[ Go to top ]

    Have you tried using a full uri for the href for the xsl stylesheet?

    I would expect the browser to want that at a minimum. But as one poster described you also want to deliver the right content type also.

    I don't quite understand why you'd want to create a browser dependency by doing things this way when you can control everything if you perform the transformation on the server instead. I think the benefits far out weight any gains you'd get by doing this on the browser side.
  27. JSP emitting XML/XSL to IEv5[ Go to top ]

    You're exactly right about the browser-dependency issue. However, for an intranet application it is much easier to specify the 'supported browser' and in this case it can make sense to take full advantage of the client's capabilities.

    On another front, I'm mainly doing things this way to be ready to take advantage of compiled transformations (eg., XSLTc from Sun). This way the transformation can safely be done at the client, as long as the client has a JDK at v1.1.4 or later.

    My overall goal is to intelligiently push as much processing as makes sense out of the over-worked server and onto the under-utilized client.

    Cheers,
    Jeff

  28. JSP emitting XML/XSL to IEv5[ Go to top ]

    hi,

    can anyone tell me how to specify the number of elements to be returned from the xml doc in xslt?

    thanks.

    ced
  29. JSP emitting XML/XSL to IEv5[ Go to top ]

    With the work I'm doing at the moment, we adopt the exact technique described in this thread of sending XML directly to clients with a reference to an XSLT stylesheet (stored server-side incidentally) attached. We add the XSLT reference to the XML server-side via the DOM createProcessingInstruction function, which is slightly different to the approach described elsewhere in this thread.

    The reason we adopt this approach is that our clients are PDAs connected to our web servers via GSM mobile phones, therefore connection speeds are dreadful. We are finding that an XML document is about a quarter or a fifth of the size of the resulting XSLT generated HTML file.

    Gareth.


  30. sir i am just a beginer and so i dont know how to embed
    or include xml into jsp sopls help me in working with jsp using xml
    thanking you

    with regards
  31. JSP emitting XML/XSL to IEv5[ Go to top ]

    Did you ever get to use it directly? What about w/ Mozilla.

    Any more tips/examples?
    TIA,
    Vic


    Here is were I am :

    JSP:
    <%@page language = "java" contentType="text/xml"%>
    <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
    <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
    <?xml version="1.0"?>
    <?xml-stylesheet href="browse.xsl" type="text/xsl" version="1.0" encoding="UTF-8" ?>

    <root>
    <metaNam><bean:message key="app.name"/></metaNam>
    <metaDesc><bean:message key="app.desc"/></metaDesc>

    <html:link page="/do/searchAct"> <bean:message key="index.link.search"/> </html:link>
    </root>

    here I stand stuck:<%@page language = "java" contentType="text/xml"%>
    <%@ taglib uri="/WEB-INF/struts-html.tld" prefix="html" %>
    <%@ taglib uri="/WEB-INF/struts-bean.tld" prefix="bean" %>
    <?xml version="1.0"?>
    <?xml-stylesheet href="browse.xsl" type="text/xsl" version="1.0" encoding="UTF-8" ?>

    <root>
    <metaNam><bean:message key="app.name"/></metaNam>
    <metaDesc><bean:message key="app.desc"/></metaDesc>

    <html:link page="/do/searchAct"> <bean:message key="index.link.search"/> </html:link>
    </root>



    XSL:

    <?xml version="1.0" ?>
    <xsl:stylesheet version ="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

     <xsl:template match="metaNam">
        <h1 align="center">
          <xsl:apply-templates/>
        </h1>
     </xsl:template>

     <xsl:template match="metaDesc">
        <p >
          <xsl:apply-templates/>
        </p>
     </xsl:template>

     <xsl:template match="field">
        <p align="right">
          <i><xsl:apply-templates/></i>
        </p>
     </xsl:template>

     <xsl:template match="label">
        <p align="left">
          <i><xsl:apply-templates/></i>
        </p>
     </xsl:template>

    </xsl:stylesheet>

    Vic
  32. It's not so complex.
    Let's say your web container name is "localhost", using port "8888", your application directory "appname".

    You should change your xml file content
    <?xml-stylesheet type="text/xsl" href="ClassInfo2.xsl" ?>
    with
    <?xml-stylesheet type="text/xsl" href="http://localhost:8888/appname/ClassInfo2.xsl" ?>.

    and that's it.


    Anton.

    > Hi Folks,
    >
    > Although I'm an experienced Java and Web developer, but I'm trying a tactic that I've seldom seen mentioned in JSP newsgroups.
    >
    > 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 in the Orion newsgroup 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 in solving my problem.]
    >
    > 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 or Tomcat 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
    >
    > Jeff dot Chapman at pervasive dot com
    > Pervasive Software