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"); %>
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE abc SYSTEM "abc.dtd">
<abc>
<timestamp><%=new java.util.Date()%></timestamp>
<Header>
<From>
<Credential domain="abc">
<Identity>[ec_order_header].sold_to_member_name</Identity>
...
<% 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
<ABC></ABC> (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
> 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 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
> >
>
> -----------------------------------------------------------
> Joseph B. Ottinger [EMAIL PROTECTED]
> http://cupid.suninternet.com/~joeo HOMES.COM Developer
>
>
===========================================================================
> 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
