[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|