Hi David,
Again, comments intermixed ;).

David Wall wrote:

> > I am going to start by making a bold statement, then support that
> statement
> > with my observations.  After introducing XML + XSLT into your architecture
> > the need for Java Server Pages disappears!
>
> This seems somewhat true to me, but it may also be a big step backwards in
> terms of capabilities.  For simple data models and simple transforms, XSLT
> will work just fine.   But if you've tried to build complex web pages using
> XSLT (for one thing, it cannot operate on multiple XML documents at the same
> time), it's a real pain, and there are not all those built-in bean methods
> and eventual taglibs that make life easier.XSLT just transforms data

> structure.  If you need to build a page that is made up of several different
> "data sets" (objects anybody?), you'd need to create a single XML document
> that contained all of these data sets so that one XSLT could transform based
> on them all.

Agreed. That's why I was thinking about using JSPs to produce the appropriate XML
(from diferent sources and pre-formatting the data if necessary) so the XSL job is
easier.


> Also, who creates the XML documents?  It no doubt is a bean.  What's the
> point of having the bean convert data into a somewhat expensive XML document
> on the server, just to have the XSLT on the server do the transform.

The reason why I'm doing so is because after I've finished producing the XML from
the data, I can let designers play with the interface and I don't need to bother
any technical people again, until the data model changes. Of course, assuming your
designers can play with XML and XSL but I'd rather train a designer to do so, which
he can also apply to other things, than teach him JSP, that he cannot apply on many
other areas, or than having a developer spending time re-adjusting the JSP every
time the UI changes.

> This may be much more powerful in the future when browsers and the like can
> take the XML+XSLT and do the work on its own end, but that's generally not
> the case now.

I'm not convinced that sending both documents to the client to be processed there
is the solution. Why send the "whole" XML document and the "whole" XSL document
throught the network and then get into client-compatibility issued when you already
know what to send in the server? Network bandwitdh and client compatibility issues
make me very cautious about that.

> XML documents are best used when they are being sent to other computer
> systems -- since XML is a nice data transfer syntax in a heterogeneous
> world.  Building and parsing DOM/XML is pretty expensive for just internal
> server representation.

Agreed. I'm just trying to see if it is worthy or not because I want the benefit of
model-view independence. And I hope that tools will help in the friendliness of
using XML/XSL and that we'll see performance improvements in the XML
parsing/processing.

Regards,
Dan

> 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

Reply via email to