This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: XSL vs. Parsing/Filling and Reading from an Object


> We are considering an XSL approach (using the Xalan processor) to
transform 
> the XML returned by the 3rd party vendor.  The things we are considering
for 
> our decision are performance, time-to-build and complexity of page 
> maintenance/creation of future pages (the current pages are read-only, but

> future pages may be transactional/editable).  

We go to some lengths to produce XML even from our own Java objects so that
XSLT can render them into HTML pages. So I bet you can guess my
recommendations... I consider the Java -> XML -> XSLT -> HTML model one of
the more rational architectures for separating content from presentation.
Certainly, having servlets utilize hash tables to build content could
potentially achieve the same separation, but it usually involves a lot more
code. To me the main issue, is getting someone to understand the functional
programming model of XSLT as opposed to the procedural model of Java (even
if they're doing proper OO your developers are still thinking in terms of
procedural logic).  

Once you get past the functional programming model all your hash table
handling goes away. As such, you are going to see big advantages in terms of
maintenance if your XML is subject to change.  You just have to change the
XSLT if properly designed it will continue to work for the most part even if
the XML has elements removed or renamed.

For handling transaction models with the XSLT approach you should look at
some form of framework.  XForms is sort of slowly creeping up on the horizon
but AFAIK isn't there yet.  We built our own framework around a single
servlet that builds template parameters (as nodesets) from submitted HTML
forms for passing back into any XSLT.  Thus, we get XSLT parameters
containing hierarchies of submitted or redisplayable data.  This allows us
to keep the style sheets generic, just matching up the data in the
parameters with the elements from the XML on the fly.   If there's no match
it means there's no pre-existing value for a given form element and things
continue on as normal...

I can't comment definitively on the performance issues for the amount of
data that you describe, but it seems to me it won't be an issue.  

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]