Re: JSPs and XML.
Anyway they will be read on the server not in the client layer. As soon as the JSP file can be transformed to HTML and WML, your application will be fine. fribeiro - Original Message - From: "Marco M" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 30, 2000 12:49 PM Subject: Re: JSPs and XML. > Hi Fernando, > yeah but i am planning to write the JSPs in XML.. > thanx > regards > marco > > > -Original Message- > > From: EXT Fernando Ribeiro [mailto:[EMAIL PROTECTED]] > > Sent: 30. May 2000 18:21 > > To: [EMAIL PROTECTED] > > Subject: Re: JSPs and XML. > > > > > > You can send HTML and WML to the browser after processing the > > JSP tags in > > JSP documents. WML seems to be a common MIME type and it will > > be understood > > by the browser in your cell phone. > > > > fribeiro > > > > - Original Message ----- > > From: "Marco M" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, May 30, 2000 11:47 AM > > Subject: Re: JSPs and XML. > > > > > > > Hi Joseph, > > > is not possible to write some jsptags for > > transforming JSP written > > > in XML into HTML or WML or other?? > > > if yes, how? > > > thanx in advance for your reply > > > regards > > > marco > > > > > > > -Original Message- > > > > From: EXT Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] > > > > Sent: 18. May 2000 11:58 > > > > To: [EMAIL PROTECTED] > > > > Subject: Re: JSPs and XML. > > > > > > > > > > > > On Thu, 18 May 2000, Shawn McKisson wrote: > > > > > > > > Coimments are interspersed. > > > > > > > > > The problem with using JSP for generating XML is that the > > > > JSP wants to > > > > > assume that it is sitting at the top level of your > > > > application, i.e. it > > > > > wants to send the response back to the client. > > > > > > > > It does? Funny, I use JSP to generate XML all the time, > > and it goes > > > > through XSL on the server... > > > > > > > > > >From what I understand, your current architecture > > looks like this > > > > > > > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via > > > > HTTP---> [client] > > > > > > > > > > If we try to introduce JSP into this scenario we get > > > > > > > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via > > HTTP--> [client] > > > > > > > > > > There is no room after the JSP layer to perform the XSL > > > > transformation > > > > > JSP does not allow for post processing of it's output in > > > > order to perform > > > > > the rendering. I believe this is because JSP is meant to be > > > > used in as > > > > > presentation generation language, not as a data mapping > > > > language. Sure, you > > > > > could chain this to another servlet which contained your > > > > rendering code, but > > > > > it is much cleaner to just have something like > > > > > > > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] > > > > ---XML--> [XSL > > > > > engine] --XML/PDF/etc. via HTTP--> [client] > > > > > > > > > > It is the requirement that JSP respond to the client > > that limits its > > > > > usefulness in this context. > > > > > > > > Um, maybe you should switch to a better app server, one > > that allows > > > > chaining based on mime types. As stated, I use a design > > something like > > > > this: > > > > > > > > [db] --data--> [beans] --> jsp --XML+XSL--> HTML > > > > > > > > The XSL can be active content itself, so the HTML is > > variable (I just > > > > haven't used it for anything else. > > > > > > > > BTW, example content can be found at > > > > http://www.orionsupport.com/ - don't > > > > let the file extensions fool you, it's all JSP, XML, XSL. > > > > > > > > > --shawn > > > > > > > > > > - Original Message - > > > > >
Re: JSPs and XML.
Sounds like he wants to use XLST to transform XSL to some other publishing format ie. WML or HTML. > -Original Message- > From: A mailing list about Java Server Pages specification and reference > [mailto:[EMAIL PROTECTED]]On Behalf Of Fernando Ribeiro > Sent: Tuesday, May 30, 2000 8:21 AM > To: [EMAIL PROTECTED] > Subject: Re: JSPs and XML. > > > You can send HTML and WML to the browser after processing the JSP tags in > JSP documents. WML seems to be a common MIME type and it will be > understood > by the browser in your cell phone. > > fribeiro > > - Original Message - > From: "Marco M" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 30, 2000 11:47 AM > Subject: Re: JSPs and XML. > > > > Hi Joseph, > > is not possible to write some jsptags for transforming > JSP written > > in XML into HTML or WML or other?? > > if yes, how? > > thanx in advance for your reply > > regards > > marco > > > > > -Original Message----- > > > From: EXT Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] > > > Sent: 18. May 2000 11:58 > > > To: [EMAIL PROTECTED] > > > Subject: Re: JSPs and XML. > > > > > > > > > On Thu, 18 May 2000, Shawn McKisson wrote: > > > > > > Coimments are interspersed. > > > > > > > The problem with using JSP for generating XML is that the > > > JSP wants to > > > > assume that it is sitting at the top level of your > > > application, i.e. it > > > > wants to send the response back to the client. > > > > > > It does? Funny, I use JSP to generate XML all the time, and it goes > > > through XSL on the server... > > > > > > > >From what I understand, your current architecture looks like this > > > > > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via > > > HTTP---> [client] > > > > > > > > If we try to introduce JSP into this scenario we get > > > > > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] > > > > > > > > There is no room after the JSP layer to perform the XSL > > > transformation > > > > JSP does not allow for post processing of it's output in > > > order to perform > > > > the rendering. I believe this is because JSP is meant to be > > > used in as > > > > presentation generation language, not as a data mapping > > > language. Sure, you > > > > could chain this to another servlet which contained your > > > rendering code, but > > > > it is much cleaner to just have something like > > > > > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] > > > ---XML--> [XSL > > > > engine] --XML/PDF/etc. via HTTP--> [client] > > > > > > > > It is the requirement that JSP respond to the client that limits its > > > > usefulness in this context. > > > > > > Um, maybe you should switch to a better app server, one that allows > > > chaining based on mime types. As stated, I use a design something like > > > this: > > > > > > [db] --data--> [beans] --> jsp --XML+XSL--> HTML > > > > > > The XSL can be active content itself, so the HTML is variable (I just > > > haven't used it for anything else. > > > > > > BTW, example content can be found at > > > http://www.orionsupport.com/ - don't > > > let the file extensions fool you, it's all JSP, XML, XSL. > > > > > > > --shawn > > > > > > > > - Original Message - > > > > From: Daniel Lopez <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Thursday, May 18, 2000 1:32 AM > > > > Subject: Re: JSPs and XML. > > > > > > > > > > > > > Hi Shawn, > > > > > > > > > > We are doing something very similar, and we might as well > > > use JSP later > > > > > down the road so I'll get you my own reasoning. > > > > > Why? Because that way you have the data generated by your action > > > > > completely independent of the way you present the data. > > > So independent > > > > > that you don't have to use Java to format this data or > > > even produce it. > > > > > For example
Re: JSPs and XML.
Hi Fernando, yeah but i am planning to write the JSPs in XML.. thanx regards marco > -Original Message- > From: EXT Fernando Ribeiro [mailto:[EMAIL PROTECTED]] > Sent: 30. May 2000 18:21 > To: [EMAIL PROTECTED] > Subject: Re: JSPs and XML. > > > You can send HTML and WML to the browser after processing the > JSP tags in > JSP documents. WML seems to be a common MIME type and it will > be understood > by the browser in your cell phone. > > fribeiro > > - Original Message - > From: "Marco M" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 30, 2000 11:47 AM > Subject: Re: JSPs and XML. > > > > Hi Joseph, > > is not possible to write some jsptags for > transforming JSP written > > in XML into HTML or WML or other?? > > if yes, how? > > thanx in advance for your reply > > regards > > marco > > > > > -Original Message----- > > > From: EXT Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] > > > Sent: 18. May 2000 11:58 > > > To: [EMAIL PROTECTED] > > > Subject: Re: JSPs and XML. > > > > > > > > > On Thu, 18 May 2000, Shawn McKisson wrote: > > > > > > Coimments are interspersed. > > > > > > > The problem with using JSP for generating XML is that the > > > JSP wants to > > > > assume that it is sitting at the top level of your > > > application, i.e. it > > > > wants to send the response back to the client. > > > > > > It does? Funny, I use JSP to generate XML all the time, > and it goes > > > through XSL on the server... > > > > > > > >From what I understand, your current architecture > looks like this > > > > > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via > > > HTTP---> [client] > > > > > > > > If we try to introduce JSP into this scenario we get > > > > > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via > HTTP--> [client] > > > > > > > > There is no room after the JSP layer to perform the XSL > > > transformation > > > > JSP does not allow for post processing of it's output in > > > order to perform > > > > the rendering. I believe this is because JSP is meant to be > > > used in as > > > > presentation generation language, not as a data mapping > > > language. Sure, you > > > > could chain this to another servlet which contained your > > > rendering code, but > > > > it is much cleaner to just have something like > > > > > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] > > > ---XML--> [XSL > > > > engine] --XML/PDF/etc. via HTTP--> [client] > > > > > > > > It is the requirement that JSP respond to the client > that limits its > > > > usefulness in this context. > > > > > > Um, maybe you should switch to a better app server, one > that allows > > > chaining based on mime types. As stated, I use a design > something like > > > this: > > > > > > [db] --data--> [beans] --> jsp --XML+XSL--> HTML > > > > > > The XSL can be active content itself, so the HTML is > variable (I just > > > haven't used it for anything else. > > > > > > BTW, example content can be found at > > > http://www.orionsupport.com/ - don't > > > let the file extensions fool you, it's all JSP, XML, XSL. > > > > > > > --shawn > > > > > > > > - Original Message - > > > > From: Daniel Lopez <[EMAIL PROTECTED]> > > > > To: <[EMAIL PROTECTED]> > > > > Sent: Thursday, May 18, 2000 1:32 AM > > > > Subject: Re: JSPs and XML. > > > > > > > > > > > > > Hi Shawn, > > > > > > > > > > We are doing something very similar, and we might as well > > > use JSP later > > > > > down the road so I'll get you my own reasoning. > > > > > Why? Because that way you have the data generated by > your action > > > > > completely independent of the way you present the data. > > > So independent > > > > > that you don't have to use Java to format this data or > > > even produce it. > > > > > For example, right now we skipped the JSP part because we
Re: JSPs and XML.
You can send HTML and WML to the browser after processing the JSP tags in JSP documents. WML seems to be a common MIME type and it will be understood by the browser in your cell phone. fribeiro - Original Message - From: "Marco M" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 30, 2000 11:47 AM Subject: Re: JSPs and XML. > Hi Joseph, > is not possible to write some jsptags for transforming JSP written > in XML into HTML or WML or other?? > if yes, how? > thanx in advance for your reply > regards > marco > > > -Original Message- > > From: EXT Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] > > Sent: 18. May 2000 11:58 > > To: [EMAIL PROTECTED] > > Subject: Re: JSPs and XML. > > > > > > On Thu, 18 May 2000, Shawn McKisson wrote: > > > > Coimments are interspersed. > > > > > The problem with using JSP for generating XML is that the > > JSP wants to > > > assume that it is sitting at the top level of your > > application, i.e. it > > > wants to send the response back to the client. > > > > It does? Funny, I use JSP to generate XML all the time, and it goes > > through XSL on the server... > > > > > >From what I understand, your current architecture looks like this > > > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via > > HTTP---> [client] > > > > > > If we try to introduce JSP into this scenario we get > > > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] > > > > > > There is no room after the JSP layer to perform the XSL > > transformation > > > JSP does not allow for post processing of it's output in > > order to perform > > > the rendering. I believe this is because JSP is meant to be > > used in as > > > presentation generation language, not as a data mapping > > language. Sure, you > > > could chain this to another servlet which contained your > > rendering code, but > > > it is much cleaner to just have something like > > > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] > > ---XML--> [XSL > > > engine] --XML/PDF/etc. via HTTP--> [client] > > > > > > It is the requirement that JSP respond to the client that limits its > > > usefulness in this context. > > > > Um, maybe you should switch to a better app server, one that allows > > chaining based on mime types. As stated, I use a design something like > > this: > > > > [db] --data--> [beans] --> jsp --XML+XSL--> HTML > > > > The XSL can be active content itself, so the HTML is variable (I just > > haven't used it for anything else. > > > > BTW, example content can be found at > > http://www.orionsupport.com/ - don't > > let the file extensions fool you, it's all JSP, XML, XSL. > > > > > --shawn > > > > > > - Original Message - > > > From: Daniel Lopez <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Thursday, May 18, 2000 1:32 AM > > > Subject: Re: JSPs and XML. > > > > > > > > > > Hi Shawn, > > > > > > > > We are doing something very similar, and we might as well > > use JSP later > > > > down the road so I'll get you my own reasoning. > > > > Why? Because that way you have the data generated by your action > > > > completely independent of the way you present the data. > > So independent > > > > that you don't have to use Java to format this data or > > even produce it. > > > > For example, right now we skipped the JSP part because we > > are generating > > > > the XML directly from PL/SQL but if we have to add some > > operations that > > > > will be done better in Java (handling files...) we just > > need to produce > > > > XML from Java and use the same XSLT sheets as the PL/SQL > > operations. Our > > > > grahical designer won't even know if we are performing > > the logic in > > > > PL/SQL or Java. And you might ask then why use JSP > > instead of generating > > > > XML directly from servlets. Well, for the same reason we > > generate HTML > > > > through JSP instead of generating it directly from > > servlets, to make the > > > > result independent of the classes that implement it, > > easier to produce > &g
Re: JSPs and XML.
Hi Joseph, is not possible to write some jsptags for transforming JSP written in XML into HTML or WML or other?? if yes, how? thanx in advance for your reply regards marco > -Original Message- > From: EXT Joseph B. Ottinger [mailto:[EMAIL PROTECTED]] > Sent: 18. May 2000 11:58 > To: [EMAIL PROTECTED] > Subject: Re: JSPs and XML. > > > On Thu, 18 May 2000, Shawn McKisson wrote: > > Coimments are interspersed. > > > The problem with using JSP for generating XML is that the > JSP wants to > > assume that it is sitting at the top level of your > application, i.e. it > > wants to send the response back to the client. > > It does? Funny, I use JSP to generate XML all the time, and it goes > through XSL on the server... > > > >From what I understand, your current architecture looks like this > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via > HTTP---> [client] > > > > If we try to introduce JSP into this scenario we get > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] > > > > There is no room after the JSP layer to perform the XSL > transformation > > JSP does not allow for post processing of it's output in > order to perform > > the rendering. I believe this is because JSP is meant to be > used in as > > presentation generation language, not as a data mapping > language. Sure, you > > could chain this to another servlet which contained your > rendering code, but > > it is much cleaner to just have something like > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] > ---XML--> [XSL > > engine] --XML/PDF/etc. via HTTP--> [client] > > > > It is the requirement that JSP respond to the client that limits its > > usefulness in this context. > > Um, maybe you should switch to a better app server, one that allows > chaining based on mime types. As stated, I use a design something like > this: > > [db] --data--> [beans] --> jsp --XML+XSL--> HTML > > The XSL can be active content itself, so the HTML is variable (I just > haven't used it for anything else. > > BTW, example content can be found at > http://www.orionsupport.com/ - don't > let the file extensions fool you, it's all JSP, XML, XSL. > > > --shawn > > > > - Original Message - > > From: Daniel Lopez <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, May 18, 2000 1:32 AM > > Subject: Re: JSPs and XML. > > > > > > > Hi Shawn, > > > > > > We are doing something very similar, and we might as well > use JSP later > > > down the road so I'll get you my own reasoning. > > > Why? Because that way you have the data generated by your action > > > completely independent of the way you present the data. > So independent > > > that you don't have to use Java to format this data or > even produce it. > > > For example, right now we skipped the JSP part because we > are generating > > > the XML directly from PL/SQL but if we have to add some > operations that > > > will be done better in Java (handling files...) we just > need to produce > > > XML from Java and use the same XSLT sheets as the PL/SQL > operations. Our > > > grahical designer won't even know if we are performing > the logic in > > > PL/SQL or Java. And you might ask then why use JSP > instead of generating > > > XML directly from servlets. Well, for the same reason we > generate HTML > > > through JSP instead of generating it directly from > servlets, to make the > > > result independent of the classes that implement it, > easier to produce > > > without getting into the code... > > > Another reason why one would want to generate XML from > JSP would be to > > > be able to forward this result to diferent XSLT and > produce WML, HTML, > > > ... using the same functionality but with diferent XSLT. > > > I understand that one might think, why add such an > overhead... Again, > > > JSPs are supposed not to be such an overhead because they > are compiled > > > into servlets the first time you access them (you might > even precompile > > > them sometimes) so they are more like a different way of > specifying your > > > output. > > > > > > So, IMHO, if you are just producing HTML, you are just > performing your > > > operations in Java and you don't have a designer that can > play XSLT, > > >
Re: JSPs and XML.
Just a question: I've read all your messages with topic called "JSPs and XML" and want to ask you for your opinion about the architecture I want to use to perform my project: (Server) [db] <-- PL/SQL --> [servlet] <--> [JSP] <-- XSL --> [XML] ^ | (Client) <-- HTTP --> [HTML] <--/ Consigue tu dirección de email gratis y permanente en http://WWW.LETTERA.NET Ýo unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name
Re: JSPs and XML.
> -Original Message- > From: Andrew S Tomlinson [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 18, 2000 11:13 AM > > My perspective would be that any basic enterprise object > (modelled as a > Bean) should be inherently capable of representing itself as > XML, maybe as > some basic override of the serialization. That way it can used in any > application. Check out Castor XML (its Open Source) http://castor.exolab.org/xml-framework.html "Castor XML is an XML databinding framework. Unlike the two main XML APIs, DOM (Document Object Model) and SAX (Simple API for XML) which deal with the structure of an XML document, Castor enables one to deal with the data defined in an XML document through an object model [beans] which represents that data." It very easiliy converts (marshalls) any bean into a corresponding XML representation, and vice-versa. Sam === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: JSPs and XML.
I think that your points here actually outline why it would be a benefit to use both JSP and XSL. For example, an average JSP on our site (after we complete the new architecture, design, and development), will first access a session bean that will log the use of the page, check to see if they have a session bean, if not it will initialize it, and check their security (via a call to LDAP) to decided if they should get the requested page or not. Then our JSP page will call Java methods that will create XML objects. So a page that is going to show a specific report, may have two or three methods that each return an XML object for that piece. The JSP page will then use an XSL tag to render the HTML. It would look like below (I don't have JSP 1.1 yet, so forgive any syntax errors please). This is very rough, but please punch holes in the idea if you can. The main idea is that JSP is the central place to call gather XML objects, wrap them in tag calls to specified XSL (which will be dynamic depending on the user and their device, etc)., use bean information and wrap it all together. <%-- This sets the session bean, logs the page and checks the security (within the bean), by checking to see what security level they have --%> <%-- this accesses the Navigation bean, which creates the table around the report (links to home page, etc) --%> <%= vpInterface.getInterface() %> <%-- this code comes from an email sent by Ryan Shriver. At present we use JSP .90, so I can't test this --%> <%-- this gets and displays the customer object --%> <%@ taglib uri="taglib.tld" prefix="stl" %> <%-- this is another XML object that will be displayed on this page --%> <%@ taglib uri="taglib.tld" prefix="stl" %> . . Shipping XML . . -- Brian N. Burridge Internet Architect Ext 3515 The Internet Group - ITSS Cox Target Media "Until a person can say deeply and honestly, "I am what I am today because of the choices I made yesterday," that person cannot say, "I choose otherwise." David Wall wrote: > > The problem with using JSP for generating XML is that the JSP wants to > > assume that it is sitting at the top level of your application, i.e. it > > wants to send the response back to the client. > > >From what I understand, your current architecture looks like this > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via HTTP---> [client] > > > > If we try to introduce JSP into this scenario we get > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] > > > > There is no room after the JSP layer to perform the XSL transformation > > JSP does not allow for post processing of it's output in order to perform > > the rendering. I believe this is because JSP is meant to be used in as > > presentation generation language, not as a data mapping language. Sure, > you > > could chain this to another servlet which contained your rendering code, > but > > it is much cleaner to just have something like > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] ---XML--> [XSL > > engine] --XML/PDF/etc. via HTTP--> [client] > > A lot depends on whether you really "need" XSLT or not. JSP is in many ways > an XSLT transform, creating output from the data in beans. XSLT transforms > XML-formated data. JSP transforms bean data. Using both seems like > overkill. JSP has the advantage in that it can merge lots of different > beans together, whereas XSLT works on only a single XML doc. Of course, if > your data comes out natively in XML format, then XSLT is a nice way to go. > > Realize that a lot of complex transforms via XSLT will likely be harder to > get right than with JSPs. For simple mapping, XSLT seems very powerful, but > it can be a complex beast when doing more complex things. > > David > > === > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: JSPs and XML.
A different angle? We are using JSP as a "scripting engine", for formatting
our backend XML. To do this we call the JSP engine (GNU, Sun) directly from
java code. Not servlet code, so we can use this anywhere in the system.
Especially since we don't want the JSP output to necessarily go to a
browser, but maybe a file or FTP site, another object etc.
We are mainly using templates like such:
<% Order oh = (Order)request.getAttribute("orderObject"); %>
<% OrderLine ol = (OrderLine)request.getAttribute("orderLineObject"); %>
<%=new java.util.Date()%>
[ec_order_header].sold_to_member_name
...
<% while ol.hasMoreElements() { %>
do stuff.
etc.
Tough design issues and possible solutions that we are facing (easy for some
I'm sure)
Observations:
* All of the data between the XML tags has to come from a source in the DB
or can be derived. (ie: current date, merging two fields)
* If there is no data then the tag becomes an empty one of the form
(Note that with a DTD any optional empty tag could be easily
removed if necessary)
* Created an XML template that has the tablename and fieldname
[tablename].fieldname between the
XML tags. (This greatly benefits developers and DB guys since it is readily
obvious what this data is in the DB world) (Ok, maybe the tags are supposed
to do that)
* Created a simple parser that converts and [tablename].fieldname to the
appropriate get method and JSP code.
* Beginning of document declares the appropriate objects and variables and
the simple parser knows which variable to prepend (ol.getMe()) to the get
method.
* Issues with data having special chars such as ">" and "<". Need a way to
deal with this.
* We also use this engine to format emails and faxes. Can now use XSLT for
view translation. (see note on this below)
* Write one translation to a standard, say RosettaNet, then use tools to map
between any other standard.
Why do it this way?
* CREATING documents using XML4J or another tool is a PITA IMHO. It is in
java code, thus harder to maintain and change. A change in the DB or
template can be done very simply in the template file, by a mere mortal.
* After JSP runs, we can validate the XML just like anywhere else.
* Provides an easy to understand model, reading a DTD isn't.
Some quick observations:
* XSL is not very easy to do. It still requires someone with more skills
than an HTML/JSP developer.
* IBM's tools are pretty cool (and free) for generating the XSL
* You spend just as much time working XSL than you would in this method
* For every new representation you have to create a new XSL, so why not just
create a new
template instead. A template can be created by a designer and not a
developer.
* Recreating a lot of EDI stuff in the XML world, kinda like a step back. No
flames please, there are benefits. ;)
* We aren't using Beans yet, but I'd like the Bean object say a PO,
serialize into XML, but that still has to be done somewhere, it's not magic.
* Between understanding Java, JSP's, Servlets, Beans, JDBC, JNI, SQL,
DBModels, and the upgrades, updates, bugs, "features", 1,000,001 development
tools, different implementations, there needs to be simple, yet powerful and
intuitive stuff (ie: jdom.org)
I may be way off on some of this stuff, this is just some observations.
- Ed
-Original Message-
From: A mailing list about Java Server Pages specification and reference
[mailto:[EMAIL PROTECTED]]On Behalf Of Shawn McKisson
Sent: Thursday, May 18, 2000 2:51 AM
To: [EMAIL PROTECTED]
Subject: Re: JSPs and XML.
I'm not arguing that the XML doesn't get processed on the server, I'm
arguing that the only way to accomplish this processing from JSP is to
introduce the notion one servlet acting like a client of another, which in
my opinion is not very clean.
I also think that the JSP-> XML solution is less flexible, because what
happens when you all of a sudden need to initiate a socket connection to a
remote machine and pass it some of your XML data through. Now your XML
mappings are tied to a front end servlet that is expecting an information
pull when what you need is an information push. Reusing the mappings will
require some weird contortion of the system.
--shawn
- Original Message -
From: Joseph B. Ottinger <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Thursday, May 18, 2000 3:58 AM
Subject: Re: JSPs and XML.
> On Thu, 18 May 2000, Shawn McKisson wrote:
>
> Coimments are interspersed.
>
> > The problem with using JSP for generating XML is that the JSP wants to
> > assume that it is sitting at the top level of your application, i.e. it
> > wants to send the response back to the client.
>
> It does? Funny, I use JSP to generate XML all the time, and it goes
> throug
Re: JSPs and XML.
> The problem with using JSP for generating XML is that the JSP wants to > assume that it is sitting at the top level of your application, i.e. it > wants to send the response back to the client. > >From what I understand, your current architecture looks like this > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via HTTP---> [client] > > If we try to introduce JSP into this scenario we get > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] > > There is no room after the JSP layer to perform the XSL transformation > JSP does not allow for post processing of it's output in order to perform > the rendering. I believe this is because JSP is meant to be used in as > presentation generation language, not as a data mapping language. Sure, you > could chain this to another servlet which contained your rendering code, but > it is much cleaner to just have something like > > [db] <-> [pl/sql] ---data---> [XML data mapping code] ---XML--> [XSL > engine] --XML/PDF/etc. via HTTP--> [client] A lot depends on whether you really "need" XSLT or not. JSP is in many ways an XSLT transform, creating output from the data in beans. XSLT transforms XML-formated data. JSP transforms bean data. Using both seems like overkill. JSP has the advantage in that it can merge lots of different beans together, whereas XSLT works on only a single XML doc. Of course, if your data comes out natively in XML format, then XSLT is a nice way to go. Realize that a lot of complex transforms via XSLT will likely be harder to get right than with JSPs. For simple mapping, XSLT seems very powerful, but it can be a complex beast when doing more complex things. David === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: JSPs and XML.
Interesting discussion. The underlying problem I see here is "where do you put the layer for converting *data* to XML ". The problem I see with using JSP as this layer is that it constrains this mapping layer to web-only applications by virtue of the dependence on the servlet objects etc. What happens if I want to render the same objects (as represented by Beans) to XML in another custom non-web application e.g. a B2B channel based on JMS or whatever. My perspective would be that any basic enterprise object (modelled as a Bean) should be inherently capable of representing itself as XML, maybe as some basic override of the serialization. That way it can used in any application. Now, in a particular web app you still might construct an *aggregate* XML file in the JSP layer by including the XML-renderings of several Beans as necessary and perhaps this can be XSLT-d into whatever output format is required. As ever, feedback is most welcome... Regards @ === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: JSPs and XML.
Hi Scott,
A simple one might look something like that:
***ShowUser.jsp*
<%@ page import="what.ever.User"%>
<%@ taglib uri="/leafTag/" prefix="leaf" %>
<%
User theUser = (User)request.getAttribute("theUser");
%>
Then if you handled previously sample XML file to the designer like:
***ShowUser.xml*
then the designer could have created the XSLT and he doesn't have to
care about Java, Beans, properties You need a more technical
designer as XSLT is not plain HTML but tools will hopefully help and
you'd need to teach them your own JSP tags so...
I hope this helps,
Dan
PD: This feature might be part of the upcomming standard taglibraries as
similar features are included in most of the modern containers (someone
mentioned Orion, I think Resin also...) Until ten , we'd rather use our
own tiny taglibrary which makes our JSPs container independent.
---
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
---
Scott Evans wrote:
>
> Can you please give an example of what the jsp page with the enclosing tag
> would look like?
> i.e. what about page directives and the like?
>
> TIA,
>
> Scott Evans
>
> > -Original Message-
> > From: Daniel Lopez [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, May 18, 2000 11:58 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: JSPs and XML.
> >
> >
> > Shawn,
> >
> > There are at least 2 method through which you can post-process the XML
> > generated in a JSP page. One is the approach that Joseph uses,
> > post-processing based in the mime-type of the answer. However, this
> > approach is container specific and we prefer to use the second one,
> > which is nothing less than using a JSP taglib that encloses your whole
> > JSP and postprocess everything in the doEndTag() method. You
> > just need a
> > JSP1.1 compatible container and the actual taglib class is
> > very simple.
> > I have tested it and it works, we are just not using it now because
> > PL/SQL is good enough for what we want to do. If we needed to process
> > some files/ access the filesystem, then I'd introduce JSPs in the mix.
> > I hope this helps,
> > Dan
> > ---
> > Daniel Lopez Janariz ([EMAIL PROTECTED])
> > Web Services
> > Computer Center
> > Balearic Islands University
> > ---
> >
> > "Joseph B. Ottinger" wrote:
> > >
> > > On Thu, 18 May 2000, Shawn McKisson wrote:
> > >
===
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: JSPs and XML.
Can you please give an example of what the jsp page with the enclosing tag would look like? i.e. what about page directives and the like? TIA, Scott Evans > -Original Message- > From: Daniel Lopez [mailto:[EMAIL PROTECTED]] > Sent: Thursday, May 18, 2000 11:58 AM > To: [EMAIL PROTECTED] > Subject: Re: JSPs and XML. > > > Shawn, > > There are at least 2 method through which you can post-process the XML > generated in a JSP page. One is the approach that Joseph uses, > post-processing based in the mime-type of the answer. However, this > approach is container specific and we prefer to use the second one, > which is nothing less than using a JSP taglib that encloses your whole > JSP and postprocess everything in the doEndTag() method. You > just need a > JSP1.1 compatible container and the actual taglib class is > very simple. > I have tested it and it works, we are just not using it now because > PL/SQL is good enough for what we want to do. If we needed to process > some files/ access the filesystem, then I'd introduce JSPs in the mix. > I hope this helps, > Dan > --- > Daniel Lopez Janariz ([EMAIL PROTECTED]) > Web Services > Computer Center > Balearic Islands University > --- > > "Joseph B. Ottinger" wrote: > > > > On Thu, 18 May 2000, Shawn McKisson wrote: > > > > Coimments are interspersed. > > > > > The problem with using JSP for generating XML is that the > JSP wants to > > > assume that it is sitting at the top level of your > application, i.e. it > > > wants to send the response back to the client. > > > > It does? Funny, I use JSP to generate XML all the time, and it goes > > through XSL on the server... > > > > > >From what I understand, your current architecture looks like this > > > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via > HTTP---> [client] > > > > > > If we try to introduce JSP into this scenario we get > > > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via > HTTP--> [client] > > > > > > There is no room after the JSP layer to perform the XSL > transformation > > > JSP does not allow for post processing of it's output in > order to perform > > > the rendering. I believe this is because JSP is meant to > be used in as > > > presentation generation language, not as a data mapping > language. Sure, you > > > could chain this to another servlet which contained your > rendering code, but > > > it is much cleaner to just have something like > > > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] > ---XML--> [XSL > > > engine] --XML/PDF/etc. via HTTP--> [client] > > > > > > It is the requirement that JSP respond to the client that > limits its > > > usefulness in this context. > > > > Um, maybe you should switch to a better app server, one that allows > > chaining based on mime types. As stated, I use a design > something like > > this: > > > > [db] --data--> [beans] --> jsp --XML+XSL--> HTML > > > > The XSL can be active content itself, so the HTML is > variable (I just > > haven't used it for anything else. > > > > BTW, example content can be found at > http://www.orionsupport.com/ - don't > > let the file extensions fool you, it's all JSP, XML, XSL. > > > > > --shawn > > > > > > - Original Message - > > > From: Daniel Lopez <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Thursday, May 18, 2000 1:32 AM > > > Subject: Re: JSPs and XML. > > > > > > > > > > Hi Shawn, > > > > > > > > We are doing something very similar, and we might as > well use JSP later > > > > down the road so I'll get you my own reasoning. > > > > Why? Because that way you have the data generated by your action > > > > completely independent of the way you present the data. > So independent > > > > that you don't have to use Java to format this data or > even produce it. > > > > For example, right now we skipped the JSP part because > we are generating > > > > the XML directly from PL/SQL but if we have to add some > operations that > > > > will be done better in Java (handling files...) we just > need to produce > > > > XML from Java and use the same XSLT sheets as the &
Re: JSPs and XML.
Sorry, I missed the bit about the Orion server on my first read through. I haven't yet seen this server - thanks for the info! That solves the chaining issues, but still has questionable flexibility... --shawn - Original Message - From: Joseph B. Ottinger <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 18, 2000 3:58 AM Subject: Re: JSPs and XML. > On Thu, 18 May 2000, Shawn McKisson wrote: > > Coimments are interspersed. > > > The problem with using JSP for generating XML is that the JSP wants to > > assume that it is sitting at the top level of your application, i.e. it > > wants to send the response back to the client. > > It does? Funny, I use JSP to generate XML all the time, and it goes > through XSL on the server... > > > >From what I understand, your current architecture looks like this > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via HTTP---> [client] > > > > If we try to introduce JSP into this scenario we get > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] > > > > There is no room after the JSP layer to perform the XSL transformation > > JSP does not allow for post processing of it's output in order to perform > > the rendering. I believe this is because JSP is meant to be used in as > > presentation generation language, not as a data mapping language. Sure, you > > could chain this to another servlet which contained your rendering code, but > > it is much cleaner to just have something like > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] ---XML--> [XSL > > engine] --XML/PDF/etc. via HTTP--> [client] > > > > It is the requirement that JSP respond to the client that limits its > > usefulness in this context. > > Um, maybe you should switch to a better app server, one that allows > chaining based on mime types. As stated, I use a design something like > this: > > [db] --data--> [beans] --> jsp --XML+XSL--> HTML > > The XSL can be active content itself, so the HTML is variable (I just > haven't used it for anything else. > > BTW, example content can be found at http://www.orionsupport.com/ - don't > let the file extensions fool you, it's all JSP, XML, XSL. > > > --shawn > > > > - Original Message - > > From: Daniel Lopez <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, May 18, 2000 1:32 AM > > Subject: Re: JSPs and XML. > > > > > > > Hi Shawn, > > > > > > We are doing something very similar, and we might as well use JSP later > > > down the road so I'll get you my own reasoning. > > > Why? Because that way you have the data generated by your action > > > completely independent of the way you present the data. So independent > > > that you don't have to use Java to format this data or even produce it. > > > For example, right now we skipped the JSP part because we are generating > > > the XML directly from PL/SQL but if we have to add some operations that > > > will be done better in Java (handling files...) we just need to produce > > > XML from Java and use the same XSLT sheets as the PL/SQL operations. Our > > > grahical designer won't even know if we are performing the logic in > > > PL/SQL or Java. And you might ask then why use JSP instead of generating > > > XML directly from servlets. Well, for the same reason we generate HTML > > > through JSP instead of generating it directly from servlets, to make the > > > result independent of the classes that implement it, easier to produce > > > without getting into the code... > > > Another reason why one would want to generate XML from JSP would be to > > > be able to forward this result to diferent XSLT and produce WML, HTML, > > > ... using the same functionality but with diferent XSLT. > > > I understand that one might think, why add such an overhead... Again, > > > JSPs are supposed not to be such an overhead because they are compiled > > > into servlets the first time you access them (you might even precompile > > > them sometimes) so they are more like a different way of specifying your > > > output. > > > > > > So, IMHO, if you are just producing HTML, you are just performing your > > > operations in Java and you don't have a designer that can play XSLT, > > > then there's no need to go for XML. But if you want to produce different > > > ouput formats reusing the same functionality, you n
Re: JSPs and XML.
I'm not arguing that the XML doesn't get processed on the server, I'm arguing that the only way to accomplish this processing from JSP is to introduce the notion one servlet acting like a client of another, which in my opinion is not very clean. I also think that the JSP-> XML solution is less flexible, because what happens when you all of a sudden need to initiate a socket connection to a remote machine and pass it some of your XML data through. Now your XML mappings are tied to a front end servlet that is expecting an information pull when what you need is an information push. Reusing the mappings will require some weird contortion of the system. --shawn - Original Message - From: Joseph B. Ottinger <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 18, 2000 3:58 AM Subject: Re: JSPs and XML. > On Thu, 18 May 2000, Shawn McKisson wrote: > > Coimments are interspersed. > > > The problem with using JSP for generating XML is that the JSP wants to > > assume that it is sitting at the top level of your application, i.e. it > > wants to send the response back to the client. > > It does? Funny, I use JSP to generate XML all the time, and it goes > through XSL on the server... > > > >From what I understand, your current architecture looks like this > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via HTTP---> [client] > > > > If we try to introduce JSP into this scenario we get > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] > > > > There is no room after the JSP layer to perform the XSL transformation > > JSP does not allow for post processing of it's output in order to perform > > the rendering. I believe this is because JSP is meant to be used in as > > presentation generation language, not as a data mapping language. Sure, you > > could chain this to another servlet which contained your rendering code, but > > it is much cleaner to just have something like > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] ---XML--> [XSL > > engine] --XML/PDF/etc. via HTTP--> [client] > > > > It is the requirement that JSP respond to the client that limits its > > usefulness in this context. > > Um, maybe you should switch to a better app server, one that allows > chaining based on mime types. As stated, I use a design something like > this: > > [db] --data--> [beans] --> jsp --XML+XSL--> HTML > > The XSL can be active content itself, so the HTML is variable (I just > haven't used it for anything else. > > BTW, example content can be found at http://www.orionsupport.com/ - don't > let the file extensions fool you, it's all JSP, XML, XSL. > > > --shawn > > > > - Original Message - > > From: Daniel Lopez <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, May 18, 2000 1:32 AM > > Subject: Re: JSPs and XML. > > > > > > > Hi Shawn, > > > > > > We are doing something very similar, and we might as well use JSP later > > > down the road so I'll get you my own reasoning. > > > Why? Because that way you have the data generated by your action > > > completely independent of the way you present the data. So independent > > > that you don't have to use Java to format this data or even produce it. > > > For example, right now we skipped the JSP part because we are generating > > > the XML directly from PL/SQL but if we have to add some operations that > > > will be done better in Java (handling files...) we just need to produce > > > XML from Java and use the same XSLT sheets as the PL/SQL operations. Our > > > grahical designer won't even know if we are performing the logic in > > > PL/SQL or Java. And you might ask then why use JSP instead of generating > > > XML directly from servlets. Well, for the same reason we generate HTML > > > through JSP instead of generating it directly from servlets, to make the > > > result independent of the classes that implement it, easier to produce > > > without getting into the code... > > > Another reason why one would want to generate XML from JSP would be to > > > be able to forward this result to diferent XSLT and produce WML, HTML, > > > ... using the same functionality but with diferent XSLT. > > > I understand that one might think, why add such an overhead... Again, > > > JSPs are supposed not to be such an overhead because they are compiled > > > into servlets the first time you access them (you might even pr
Re: JSPs and XML.
Shawn, There are at least 2 method through which you can post-process the XML generated in a JSP page. One is the approach that Joseph uses, post-processing based in the mime-type of the answer. However, this approach is container specific and we prefer to use the second one, which is nothing less than using a JSP taglib that encloses your whole JSP and postprocess everything in the doEndTag() method. You just need a JSP1.1 compatible container and the actual taglib class is very simple. I have tested it and it works, we are just not using it now because PL/SQL is good enough for what we want to do. If we needed to process some files/ access the filesystem, then I'd introduce JSPs in the mix. I hope this helps, Dan --- Daniel Lopez Janariz ([EMAIL PROTECTED]) Web Services Computer Center Balearic Islands University --- "Joseph B. Ottinger" wrote: > > On Thu, 18 May 2000, Shawn McKisson wrote: > > Coimments are interspersed. > > > The problem with using JSP for generating XML is that the JSP wants to > > assume that it is sitting at the top level of your application, i.e. it > > wants to send the response back to the client. > > It does? Funny, I use JSP to generate XML all the time, and it goes > through XSL on the server... > > > >From what I understand, your current architecture looks like this > > > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via HTTP---> [client] > > > > If we try to introduce JSP into this scenario we get > > > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] > > > > There is no room after the JSP layer to perform the XSL transformation > > JSP does not allow for post processing of it's output in order to perform > > the rendering. I believe this is because JSP is meant to be used in as > > presentation generation language, not as a data mapping language. Sure, you > > could chain this to another servlet which contained your rendering code, but > > it is much cleaner to just have something like > > > > [db] <-> [pl/sql] ---data---> [XML data mapping code] ---XML--> [XSL > > engine] --XML/PDF/etc. via HTTP--> [client] > > > > It is the requirement that JSP respond to the client that limits its > > usefulness in this context. > > Um, maybe you should switch to a better app server, one that allows > chaining based on mime types. As stated, I use a design something like > this: > > [db] --data--> [beans] --> jsp --XML+XSL--> HTML > > The XSL can be active content itself, so the HTML is variable (I just > haven't used it for anything else. > > BTW, example content can be found at http://www.orionsupport.com/ - don't > let the file extensions fool you, it's all JSP, XML, XSL. > > > --shawn > > > > - Original Message - > > From: Daniel Lopez <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Thursday, May 18, 2000 1:32 AM > > Subject: Re: JSPs and XML. > > > > > > > Hi Shawn, > > > > > > We are doing something very similar, and we might as well use JSP later > > > down the road so I'll get you my own reasoning. > > > Why? Because that way you have the data generated by your action > > > completely independent of the way you present the data. So independent > > > that you don't have to use Java to format this data or even produce it. > > > For example, right now we skipped the JSP part because we are generating > > > the XML directly from PL/SQL but if we have to add some operations that > > > will be done better in Java (handling files...) we just need to produce > > > XML from Java and use the same XSLT sheets as the PL/SQL operations. Our > > > grahical designer won't even know if we are performing the logic in > > > PL/SQL or Java. And you might ask then why use JSP instead of generating > > > XML directly from servlets. Well, for the same reason we generate HTML > > > through JSP instead of generating it directly from servlets, to make the > > > result independent of the classes that implement it, easier to produce > > > without getting into the code... > > > Another reason why one would want to generate XML from JSP would be to > > > be able to forward this result to diferent XSLT and produce WML, HTML, > > > ... using the same functionality but with diferent XSLT. > > > I understand that one might think, why add such an overhead... Again, > > > JSPs are supposed not to be such an overhead b
Réf. : Re: JSPs and XML.
this does actually depend on the JSP container you are using, a lot of them are providing this JSP-XML-XSLT-Response feature. check out www.orionserver.com, for example, : they produce a J2EE application server that will, among other things, process XSL-Transformations on JSP-produced XML content if you use a directive. cheers, nb Shawn McKisson <[EMAIL PROTECTED]>@JAVA.SUN.COM> le 18.05.2000 09:20:19 Veuillez répondre à A mailing list about Java Server Pages specification and reference <[EMAIL PROTECTED]> Envoyé par : A mailing list about Java Server Pages specification and reference <[EMAIL PROTECTED]> Pour :[EMAIL PROTECTED] cc : Objet : Re: JSPs and XML. The problem with using JSP for generating XML is that the JSP wants to assume that it is sitting at the top level of your application, i.e. it wants to send the response back to the client. >From what I understand, your current architecture looks like this [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via HTTP---> [client] If we try to introduce JSP into this scenario we get [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] There is no room after the JSP layer to perform the XSL transformation JSP does not allow for post processing of it's output in order to perform the rendering. I believe this is because JSP is meant to be used in as presentation generation language, not as a data mapping language. Sure, you could chain this to another servlet which contained your rendering code, but it is much cleaner to just have something like [db] <-> [pl/sql] ---data---> [XML data mapping code] ---XML--> [XSL engine] --XML/PDF/etc. via HTTP--> [client] It is the requirement that JSP respond to the client that limits its usefulness in this context. --shawn - Original Message - From: Daniel Lopez <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 18, 2000 1:32 AM Subject: Re: JSPs and XML. > Hi Shawn, > > We are doing something very similar, and we might as well use JSP later > down the road so I'll get you my own reasoning. > Why? Because that way you have the data generated by your action > completely independent of the way you present the data. So independent > that you don't have to use Java to format this data or even produce it. > For example, right now we skipped the JSP part because we are generating > the XML directly from PL/SQL but if we have to add some operations that > will be done better in Java (handling files...) we just need to produce > XML from Java and use the same XSLT sheets as the PL/SQL operations. Our > grahical designer won't even know if we are performing the logic in > PL/SQL or Java. And you might ask then why use JSP instead of generating > XML directly from servlets. Well, for the same reason we generate HTML > through JSP instead of generating it directly from servlets, to make the > result independent of the classes that implement it, easier to produce > without getting into the code... > Another reason why one would want to generate XML from JSP would be to > be able to forward this result to diferent XSLT and produce WML, HTML, > ... using the same functionality but with diferent XSLT. > I understand that one might think, why add such an overhead... Again, > JSPs are supposed not to be such an overhead because they are compiled > into servlets the first time you access them (you might even precompile > them sometimes) so they are more like a different way of specifying your > output. > > So, IMHO, if you are just producing HTML, you are just performing your > operations in Java and you don't have a designer that can play XSLT, > then there's no need to go for XML. But if you want to produce different > ouput formats reusing the same functionality, you need to seamlesly > integrate different sources of the information into your HTML layer or > you have a designer that can play XSLT then you can get some advantages > by using XML and you might want to produce it from Java through JSP. > > Just my 2ec > Dan > --- > Daniel Lopez Janariz ([EMAIL PROTECTED]) > Web Services > Computer Center > Balearic Islands University > --- > > > Shawn McKisson wrote: > > > > Why would you want to take data, convert it into another form of data and > > *then* convert it into HTML? > > > > This is like pouring yourself a cold beer by first pouring it from the > > bottle into one mug, then pouring that mug into another mug. > > > > If a you have a JSP page which does emit XML, you could chain the output of > > that page through another servlet which performed the XML/XSL conversion.
Re: JSPs and XML.
On Thu, 18 May 2000, Shawn McKisson wrote: Coimments are interspersed. > The problem with using JSP for generating XML is that the JSP wants to > assume that it is sitting at the top level of your application, i.e. it > wants to send the response back to the client. It does? Funny, I use JSP to generate XML all the time, and it goes through XSL on the server... > >From what I understand, your current architecture looks like this > > [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via HTTP---> [client] > > If we try to introduce JSP into this scenario we get > > [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] > > There is no room after the JSP layer to perform the XSL transformation > JSP does not allow for post processing of it's output in order to perform > the rendering. I believe this is because JSP is meant to be used in as > presentation generation language, not as a data mapping language. Sure, you > could chain this to another servlet which contained your rendering code, but > it is much cleaner to just have something like > > [db] <-> [pl/sql] ---data---> [XML data mapping code] ---XML--> [XSL > engine] --XML/PDF/etc. via HTTP--> [client] > > It is the requirement that JSP respond to the client that limits its > usefulness in this context. Um, maybe you should switch to a better app server, one that allows chaining based on mime types. As stated, I use a design something like this: [db] --data--> [beans] --> jsp --XML+XSL--> HTML The XSL can be active content itself, so the HTML is variable (I just haven't used it for anything else. BTW, example content can be found at http://www.orionsupport.com/ - don't let the file extensions fool you, it's all JSP, XML, XSL. > --shawn > > - Original Message - > From: Daniel Lopez <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Thursday, May 18, 2000 1:32 AM > Subject: Re: JSPs and XML. > > > > Hi Shawn, > > > > We are doing something very similar, and we might as well use JSP later > > down the road so I'll get you my own reasoning. > > Why? Because that way you have the data generated by your action > > completely independent of the way you present the data. So independent > > that you don't have to use Java to format this data or even produce it. > > For example, right now we skipped the JSP part because we are generating > > the XML directly from PL/SQL but if we have to add some operations that > > will be done better in Java (handling files...) we just need to produce > > XML from Java and use the same XSLT sheets as the PL/SQL operations. Our > > grahical designer won't even know if we are performing the logic in > > PL/SQL or Java. And you might ask then why use JSP instead of generating > > XML directly from servlets. Well, for the same reason we generate HTML > > through JSP instead of generating it directly from servlets, to make the > > result independent of the classes that implement it, easier to produce > > without getting into the code... > > Another reason why one would want to generate XML from JSP would be to > > be able to forward this result to diferent XSLT and produce WML, HTML, > > ... using the same functionality but with diferent XSLT. > > I understand that one might think, why add such an overhead... Again, > > JSPs are supposed not to be such an overhead because they are compiled > > into servlets the first time you access them (you might even precompile > > them sometimes) so they are more like a different way of specifying your > > output. > > > > So, IMHO, if you are just producing HTML, you are just performing your > > operations in Java and you don't have a designer that can play XSLT, > > then there's no need to go for XML. But if you want to produce different > > ouput formats reusing the same functionality, you need to seamlesly > > integrate different sources of the information into your HTML layer or > > you have a designer that can play XSLT then you can get some advantages > > by using XML and you might want to produce it from Java through JSP. > > > > Just my 2ec > > Dan > > --- > > Daniel Lopez Janariz ([EMAIL PROTECTED]) > > Web Services > > Computer Center > > Balearic Islands University > > --- > > > > > > Shawn McKisson wrote: > > > > > > Why would you want to take data, convert it into another form of data > and > > > *then* convert it into HTML? > > > > > > This is li
Re: JSPs and XML.
The problem with using JSP for generating XML is that the JSP wants to assume that it is sitting at the top level of your application, i.e. it wants to send the response back to the client. >From what I understand, your current architecture looks like this [db] <-> [pl/sql] ---XML---> [XSL engine] --HTML via HTTP---> [client] If we try to introduce JSP into this scenario we get [db] <-> [pl/sql] ---data---> [JSP] ---XML via HTTP--> [client] There is no room after the JSP layer to perform the XSL transformation JSP does not allow for post processing of it's output in order to perform the rendering. I believe this is because JSP is meant to be used in as presentation generation language, not as a data mapping language. Sure, you could chain this to another servlet which contained your rendering code, but it is much cleaner to just have something like [db] <-> [pl/sql] ---data---> [XML data mapping code] ---XML--> [XSL engine] --XML/PDF/etc. via HTTP--> [client] It is the requirement that JSP respond to the client that limits its usefulness in this context. --shawn - Original Message - From: Daniel Lopez <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Thursday, May 18, 2000 1:32 AM Subject: Re: JSPs and XML. > Hi Shawn, > > We are doing something very similar, and we might as well use JSP later > down the road so I'll get you my own reasoning. > Why? Because that way you have the data generated by your action > completely independent of the way you present the data. So independent > that you don't have to use Java to format this data or even produce it. > For example, right now we skipped the JSP part because we are generating > the XML directly from PL/SQL but if we have to add some operations that > will be done better in Java (handling files...) we just need to produce > XML from Java and use the same XSLT sheets as the PL/SQL operations. Our > grahical designer won't even know if we are performing the logic in > PL/SQL or Java. And you might ask then why use JSP instead of generating > XML directly from servlets. Well, for the same reason we generate HTML > through JSP instead of generating it directly from servlets, to make the > result independent of the classes that implement it, easier to produce > without getting into the code... > Another reason why one would want to generate XML from JSP would be to > be able to forward this result to diferent XSLT and produce WML, HTML, > ... using the same functionality but with diferent XSLT. > I understand that one might think, why add such an overhead... Again, > JSPs are supposed not to be such an overhead because they are compiled > into servlets the first time you access them (you might even precompile > them sometimes) so they are more like a different way of specifying your > output. > > So, IMHO, if you are just producing HTML, you are just performing your > operations in Java and you don't have a designer that can play XSLT, > then there's no need to go for XML. But if you want to produce different > ouput formats reusing the same functionality, you need to seamlesly > integrate different sources of the information into your HTML layer or > you have a designer that can play XSLT then you can get some advantages > by using XML and you might want to produce it from Java through JSP. > > Just my 2ec > Dan > --- > Daniel Lopez Janariz ([EMAIL PROTECTED]) > Web Services > Computer Center > Balearic Islands University > --- > > > Shawn McKisson wrote: > > > > Why would you want to take data, convert it into another form of data and > > *then* convert it into HTML? > > > > This is like pouring yourself a cold beer by first pouring it from the > > bottle into one mug, then pouring that mug into another mug. > > > > If a you have a JSP page which does emit XML, you could chain the output of > > that page through another servlet which performed the XML/XSL conversion. So > > the XML/XSL servlet would use the JSP page as a data source. > > > > There were some really good articles about 7-12 months ago on XML-INTEREST > > about this. > > If I can find them I will mail them to you. > > > > --shawn > > > > - Original Message - > > From: Robert Nicholson <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Wednesday, May 17, 2000 5:10 AM > > Subject: Re: JSPs and XML. > > > > > I would like to know if a JSP app emits XML what component of existing > > > application servers can translate that to whatever presentation language > > is > >
Re: JSPs and XML.
Hi Shawn, We are doing something very similar, and we might as well use JSP later down the road so I'll get you my own reasoning. Why? Because that way you have the data generated by your action completely independent of the way you present the data. So independent that you don't have to use Java to format this data or even produce it. For example, right now we skipped the JSP part because we are generating the XML directly from PL/SQL but if we have to add some operations that will be done better in Java (handling files...) we just need to produce XML from Java and use the same XSLT sheets as the PL/SQL operations. Our grahical designer won't even know if we are performing the logic in PL/SQL or Java. And you might ask then why use JSP instead of generating XML directly from servlets. Well, for the same reason we generate HTML through JSP instead of generating it directly from servlets, to make the result independent of the classes that implement it, easier to produce without getting into the code... Another reason why one would want to generate XML from JSP would be to be able to forward this result to diferent XSLT and produce WML, HTML, ... using the same functionality but with diferent XSLT. I understand that one might think, why add such an overhead... Again, JSPs are supposed not to be such an overhead because they are compiled into servlets the first time you access them (you might even precompile them sometimes) so they are more like a different way of specifying your output. So, IMHO, if you are just producing HTML, you are just performing your operations in Java and you don't have a designer that can play XSLT, then there's no need to go for XML. But if you want to produce different ouput formats reusing the same functionality, you need to seamlesly integrate different sources of the information into your HTML layer or you have a designer that can play XSLT then you can get some advantages by using XML and you might want to produce it from Java through JSP. Just my 2ec Dan --- Daniel Lopez Janariz ([EMAIL PROTECTED]) Web Services Computer Center Balearic Islands University --- Shawn McKisson wrote: > > Why would you want to take data, convert it into another form of data and > *then* convert it into HTML? > > This is like pouring yourself a cold beer by first pouring it from the > bottle into one mug, then pouring that mug into another mug. > > If a you have a JSP page which does emit XML, you could chain the output of > that page through another servlet which performed the XML/XSL conversion. So > the XML/XSL servlet would use the JSP page as a data source. > > There were some really good articles about 7-12 months ago on XML-INTEREST > about this. > If I can find them I will mail them to you. > > --shawn > > - Original Message - > From: Robert Nicholson <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, May 17, 2000 5:10 AM > Subject: Re: JSPs and XML. > > > I would like to know if a JSP app emits XML what component of existing > > application servers can translate that to whatever presentation language > is > > prefered? I want to understand how XSLT fits into a JSP app's > architecture. > > > > - Original Message ----- > > From: "Shawn McKisson" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, May 16, 2000 9:15 PM > > Subject: Re: JSPs and XML. > > > > > > > Just return XML tags instead of only HTML tags. > > > There is nothing special that needs to be done. > > > > > > If you are going to just turn around and reprocess the XML into HTML > using > > > something like XSL, then you are basically needlessly supporting two > > > presentation layers. You should reconsider your app architecture. > > > > > > --shawn > > > > > > - Original Message - > > > From: Bilal Ali Nawaz <[EMAIL PROTECTED]> > > > To: <[EMAIL PROTECTED]> > > > Sent: Tuesday, May 16, 2000 1:36 AM > > > Subject: JSPs and XML. > > > > > > > > > > hi all, > > > > can anyone please direct me to some useful resources on the web > > concerning > > > how > > > > to output XML through a JSP? basically what i want to study is that > can > > > XML be > > > > 'thrown' by a jsp just like HTML? and if so, how?? > > > > > > > > thanking all of you in advance, > > > > bilal. > > > > > > _ > > > > > > > &g
Re: JSPs and XML.
Why would you want to take data, convert it into another form of data and *then* convert it into HTML? This is like pouring yourself a cold beer by first pouring it from the bottle into one mug, then pouring that mug into another mug. If a you have a JSP page which does emit XML, you could chain the output of that page through another servlet which performed the XML/XSL conversion. So the XML/XSL servlet would use the JSP page as a data source. There were some really good articles about 7-12 months ago on XML-INTEREST about this. If I can find them I will mail them to you. --shawn - Original Message - From: Robert Nicholson <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, May 17, 2000 5:10 AM Subject: Re: JSPs and XML. > I would like to know if a JSP app emits XML what component of existing > application servers can translate that to whatever presentation language is > prefered? I want to understand how XSLT fits into a JSP app's architecture. > > - Original Message - > From: "Shawn McKisson" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 16, 2000 9:15 PM > Subject: Re: JSPs and XML. > > > > Just return XML tags instead of only HTML tags. > > There is nothing special that needs to be done. > > > > If you are going to just turn around and reprocess the XML into HTML using > > something like XSL, then you are basically needlessly supporting two > > presentation layers. You should reconsider your app architecture. > > > > --shawn > > > > - Original Message - > > From: Bilal Ali Nawaz <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Tuesday, May 16, 2000 1:36 AM > > Subject: JSPs and XML. > > > > > > > hi all, > > > can anyone please direct me to some useful resources on the web > concerning > > how > > > to output XML through a JSP? basically what i want to study is that can > > XML be > > > 'thrown' by a jsp just like HTML? and if so, how?? > > > > > > thanking all of you in advance, > > > bilal. > > > > _ > > > > > > Disclaimer: > > > > > > "This message is confidential. It may also be privileged or otherwise > > protected > > > by legal rules. If you have received it by mistake please let us know > by > > reply > > > and then delete it from your system." > > > > > > > > > === > > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > > JSP-INTEREST". > > > Some relevant FAQs on JSP/Servlets can be found at: > > > > > > http://java.sun.com/products/jsp/faq.html > > > http://www.esperanto.org.nz/jsp/jspfaq.html > > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > > > > > > > > === > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > > Some relevant FAQs on JSP/Servlets can be found at: > > > > http://java.sun.com/products/jsp/faq.html > > http://www.esperanto.org.nz/jsp/jspfaq.html > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > > > > === > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: JSPs and XML.
I would like to know if a JSP app emits XML what component of existing application servers can translate that to whatever presentation language is prefered? I want to understand how XSLT fits into a JSP app's architecture. - Original Message - From: "Shawn McKisson" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 16, 2000 9:15 PM Subject: Re: JSPs and XML. > Just return XML tags instead of only HTML tags. > There is nothing special that needs to be done. > > If you are going to just turn around and reprocess the XML into HTML using > something like XSL, then you are basically needlessly supporting two > presentation layers. You should reconsider your app architecture. > > --shawn > > - Original Message - > From: Bilal Ali Nawaz <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Tuesday, May 16, 2000 1:36 AM > Subject: JSPs and XML. > > > > hi all, > > can anyone please direct me to some useful resources on the web concerning > how > > to output XML through a JSP? basically what i want to study is that can > XML be > > 'thrown' by a jsp just like HTML? and if so, how?? > > > > thanking all of you in advance, > > bilal. > > _ > > > > Disclaimer: > > > > "This message is confidential. It may also be privileged or otherwise > protected > > by legal rules. If you have received it by mistake please let us know by > reply > > and then delete it from your system." > > > > > === > > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff > JSP-INTEREST". > > Some relevant FAQs on JSP/Servlets can be found at: > > > > http://java.sun.com/products/jsp/faq.html > > http://www.esperanto.org.nz/jsp/jspfaq.html > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > > > > === > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
Re: JSPs and XML.
Just return XML tags instead of only HTML tags. There is nothing special that needs to be done. If you are going to just turn around and reprocess the XML into HTML using something like XSL, then you are basically needlessly supporting two presentation layers. You should reconsider your app architecture. --shawn - Original Message - From: Bilal Ali Nawaz <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, May 16, 2000 1:36 AM Subject: JSPs and XML. > hi all, > can anyone please direct me to some useful resources on the web concerning how > to output XML through a JSP? basically what i want to study is that can XML be > 'thrown' by a jsp just like HTML? and if so, how?? > > thanking all of you in advance, > bilal. > _ > > Disclaimer: > > "This message is confidential. It may also be privileged or otherwise protected > by legal rules. If you have received it by mistake please let us know by reply > and then delete it from your system." > > === > To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". > Some relevant FAQs on JSP/Servlets can be found at: > > http://java.sun.com/products/jsp/faq.html > http://www.esperanto.org.nz/jsp/jspfaq.html > http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP > http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets > === To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST". Some relevant FAQs on JSP/Servlets can be found at: http://java.sun.com/products/jsp/faq.html http://www.esperanto.org.nz/jsp/jspfaq.html http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
