Help me eradicate xsl from my system

[Julia Reynolds]

Help me make good arguments for implementing Velocity as a template engine to replace ubiquitous xsl! We use xsl to tranform xml into everything else, but I want to use Velocity, at least to format outgoing emails and reports. How can I defeat the "xsl is so very powerful" argument in this situation? Can I?

J

[Karthik Guru]

My first impressions about VTL ( velocity template language) is that it is way far easier than XSL. XSL works on top of the xml that you supply while Velocity reads data out the java objects you populate in the Velocity context. Anybody can write java beans and VTL definitely looks lot simpler than XSL.
I mean for stuff like email templates I think you should give velocity a shot. I also think (the author / someone has to confirm) that content generation using velocity would be faster than corresponding xsl transform?..just a guess)

[Alexandru Popescu]

Hi Julia!

Even if both solutions can be used for generation, I think their aim is quite different. While XSL is involved in an XML context (so to transform XML format data), Velocity use an objectual context. So considering that at this moment your environment use a lot of XML content (in order to enable XSL usage) you will have to migrate this to objects - solution that is not quite easy.
As always, I would say that you must choose the best solution for the problem.

./pope

[Alexandru Popescu]

Originally posted by Karthik Guru:
My first impressions about VTL ( velocity template language) is that it is way far easier than XSL.

I am not quite sure about this. In both cases you have a small learning curve to follow.

XSL works on top of the xml that you supply while Velocity reads data out the java objects you populate in the Velocity context.

This is quite important. If existing data is in XML format, migrating to objects is not allows an easy one and moreover can be counter productive.

that content generation using velocity would be faster than corresponding xsl transform?..just a guess)

Considering that mainly XSL transformation requires a in-memory DOM I would say that you are somehow write .

./pope

[Karthik Guru]

I am not quite sure about this. In both cases you have a small learning curve to follow.


Hi Ali,

May be i'm missing something here because I have not used velocity.
But VTL did look pretty simple..there were'nt many constructs and I have always struggled with XSL

thanks.

[Alexandru Popescu]

I am not the advocate of any of the solution. I use both in different context - where using the other is by far not appropriate.
Where I really see a big difference is in debugging. While debugging velocity is quite easy (Java debugging), XSL debugging is quite a killer without the appropriate tool.

./pope

[Karthik Guru]

Just saw this Anakia and looks like it might address your problem.
Looks like it builds on top of Velocity and allows you to transform xml through velocity templates. JDOM is what it uses to parse the xml document. The template has access to some implicit objects( like document root etc) that you can use to extract data from XML using jdom apis.

I could see an ANT interface, you might have to investigate further for a programmatic interface for transformation.

[David Harkness]

I'm curious about this too. I wasn't involved with the selection or implementation of XSL in our web layer, but I do know how it lays out. We expose Java beans from our business layer and used to have JSPs present the data as HTML.

Our new presentation layer uses helper classes to build XML documents (DOM -> XML String) from the beans and XSLs (allowing skinning by pointing to a different XSL URL) to create HTML. While this does the job, it seems the choice of XSL was a matter of "wow, XSL is a neat new technology."

Most of us had experience with JSPs, and those with minimal exposure could have more easily picked up Velocity (or something similar). As it is now, most of our developers need assistance to make the dev/QA-only "white" XSLs while a new separate team creates and maintains the customer-facnig XSLs.

Perhaps XSLT compilers can help performance, but as I consider what a single bean attribute goes through to get from a bean to HTML I wonder whether all that is overkill.

It's more interesting to me now as we're rewriting the majority of the business layer right now. The original architecture put all of the business logic into the processor classes (our framework equivalent of the Struts Action class). As we're rewriting our persistence layer already (stateless session and entity beans to Spring/Hibernate), it seems nows as good a time as any to migrate the BL into a true BL layer, separating it from presentation code.

Any change would be at least six months down the road, so I've got smoe time to investigate the other options. Does the book compare Velocity to other technologies in depth?

[Alexandru Popescu]

David, if you really are in position of evaluating other web tier solutions, I would suggest to take a look in the following directions (taking into account you are saying the business + persistence tier is moving to Spring):

Spring + Struts + Tiles

Spring + AppFuse (+ Tiles/SiteMesh)

Spring + Spring MVC (+ SiteMesh)

However keep in mind that migrating from XSL to any other solution will take a very long time, big efforts and will represent a real shift in your dev environment.

./pope

[Rob Harrop]

Okay, I'll try to reply to/summarise all the points made in this topic so far.

First of all, Velocity and XSL are really two separate beasts. As was mentioned in an earlier post, Velocity works on graphs of objects and XSL works on trees of XML nodes. That said, Velocity provides the JDOM-based Anakia, which is an Ant based XML transformation tool that works by pulling out nodes using a simple JavaBean syntax. Velocity also provides Declarative Velocity Style Language (DVSL) which is a VTL-based XML transformation language similar to XSL.

DVSL syntax is very simple (more so than XSL) but at the same time retains much of the power you get from XSL. On the downside, DVSL is not at release level although the quality of the indevelopment code is pretty high. I cover both Anakia and DVSL in the book.

My experience with XSL has been quite bumpy, and out of around 20 considered use cases we have only ever found one that was valid, which was to transform data that already existed into XML into some other XML format.

As an earlier poster described, I once considered transforming Java objects into XML and then transforming the XML into HTML or whatever for rendering. At first this sounds like a great idea since you can swap out one stylesheet for another and get a completely new look. However, the performance of such a solution is, in general, diabolical when compared Velocity or JSP. Unless your data is already in XML format, by that I mean it is stored in XML or arrives to you in XML, then I would recommend using Java objects to represent the model data and Velocity templates to render the view.

You can easily swap out one Velocity template for another when using an MVC framework such as Struts or Spring which hides the path of the template from the end user. My general preference for building a web application is to use Spring or Struts coupled with Velocity at the front-end. I can easily modify the look of my applications by replacing a few templates which are much easier to write than XSL templates.

Rob

[Alexandru Popescu]

Firstly, thanks Rob for confirming my thoughts. Than I would like to comment on this:

As an earlier poster described, I once considered transforming Java objects into XML and then transforming the XML into HTML or whatever for rendering. At first this sounds like a great idea since you can swap out one stylesheet for another and get a completely new look. However, the performance of such a solution is, in general, diabolical when compared Velocity or JSP. Unless your data is already in XML format, by that I mean it is stored in XML or arrives to you in XML, then I would recommend using Java objects to represent the model data and Velocity templates to render the view.

.

I very much agree with you and I would like to underline the fact that the other way around (loading XML data into objects and that creating the necessary Velocity context) may be at its turn an overkill.

./pope

[Rob Harrop]

Ali,

Certainly, transforming data into XML just so you can transform it into another form is generally wasted effort and offers no real benefit for your application.

Stick with a simple object model that you render using Velocity (or JSP) and you will avoid stunting your application with unnecessary complexity.

Rob

[Alexandru Popescu]

Originally posted by Rob Harrop:
Ali,

Certainly, transforming data into XML just so you can transform it into another form is generally wasted effort and offers no real benefit for your application.

Stick with a simple object model that you render using Velocity (or JSP) and you will avoid stunting your application with unnecessary complexity.

Rob

I guess I wasn't clear enough: what I wanted to tell was that transforming existing XML format data into objects is also an overkill .

./pope

[Julia Reynolds]

Thanks everyone for interesting and thought-provoking responses! Hopefully I can use some of these arguments to velocitize our system. So far I've only managed to sneak velocity into a code generator tool I wrote to help produce jsp code for new screens, but it's a start :-)

Julia

[Alexandru Popescu]

Nice start. Good luck and keep in mind the KISS!

./pope

[David Harkness]

Originally posted by Ali Pope:
However keep in mind that migrating from XSL to any other solution will take a very long time, big efforts and will represent a real shift in your dev environment.

Yes, I suspect this would be a hard sell. The only reason I would entertain it is that we are already reworking the logic in the presentation layer and then reskinning the site (certainly adding new features requiring more web tier changes).

I'll need to determine just how much of a hit generating a DOM and XML string from the Java beans and transforming it into HTML takes. Unfortunately, cost tends to override all other considerations, and cost of maintenance is usually overlooked. As it is we've moved to Spring+Hibernate only because we can save half a million a year by ditching WebLogic.