About Overview Getting Started Download Install Design Contributors ChangeLog Coding Standards License TODO Report Issues Community Powered By Velocity Get Involved Mailing Lists CVS Repositories Docs User's Guide (English) User's Guide (Finnish) Developer's Guide VTL Reference Guide Specification Javadoc Tools Tool Subproject Anakia : XML->doc tool Texen : text generation DVSL : XML xformation Veltag : JSP taglib Migration to Velocity Editors and IDEs Comparisons YMTD VM/WM Differences JSP vs. Velocity XMLC vs. Velocity Site Translations English Japanese |
Case Study: XMLC vs. Velocity
> A while ago, a question was asked on a Jakarta Tomcat mailing list about XMLC and Velocity. Bojan Smojver <bojan@binarix.com> gave this thoughtful reply, and gave us permission to present it here on the Velocity site.
>     I found this in the tutorial for XMLC:

>     ------------------
>     XMLC is a Java-based compiler that takes a document written in the
>     Hypertext Markup Language (HTML) or the eXtensible Markup Language (XML)
>     and creates Java classes that will faithfully recreate the document. The
>     resulting Java classes can be used to insert dynamic content into the
>     document framework at run time. XMLC, therefore, is a wonderful way to
>     create dynamic HTML or XML documents from Java.
>     ------------------

>     This sounds awfully like JSP to me, which is reason #1 why someone would
>     use Velocity.

>     Although I use Velocity for my web work, Velocity is a generic template
>     engine, it doesn't really care about the rest of the content. And that's
>     great!

>     I use XSLT (sorry Jon, promise to give Anakia another look :-) to
>     prepare my documents from XML into XHTML (this is not done at run time,
>     not like Cocoon) and Velocity doesn't get upset much by that (except for
>     the fact that you can't have '&&' (VTL and) in XSLT without applying a
>     few tricks) but I've overcome that through Ant's nice replacement
>     techniques...

>     Anyway, the first bad point to XMLC goes for the pains of code
>     generation, which Velocity avoids so neatly.

>     The second is the actual process of designing the complete solution
>     which is pictured here:
>     http://xmlc.enhydra.org/project/aboutProject/index.html

>     Designer designs the page and then engineer puts in the logic? This
>     sounds very bad to me. There should be a 'box full of Lego's' designers
>     can choose their functionality from, not the other way around. If
>     engineers have to be involved in simple projects, it comes back to
>     employing engineers to do everything in the first place. And why
>     wouldn't you use even JSP or ECS in such a case? You're are mucking
>     around with Java again... The XMLC cycle is just too long and it doesn't
>     make sense at all - what happens when a designer (by mistake or
>     intentionally) screws up the id's in the page? All of the engineers code
>     becomes unusable. Now that's a nice separation between presentation and
>     functionality!

>     Second bad point.

>     An example from my 'production line', which illustrates how Velocity
>     handles the above. I have a few classes that handle all inquiry forms:
>     one class handles the fields from the form and stores those into a
>     database, the other one picks the fields and mails them to designated
>     e-mail address. These classes are beans and are loaded from the only
>     servlet I ever use (licensed GPL, but could contain any number of bugs
>     since I wrote it), which handles ALL Velocity pages: 331 lines long
>     including comments. Beans have scope and all, just like with JSP's.

>     Once the first ever form is created and debugged, an imaginary web
>     designer on my 'production line' would copy and existing Velocity page
>     from a previous project, change the fields (their names, their number...
>     whatever) in it and the other content. Once they post the page on the
>     site, that's it. It just works. They didn't even have to talk to an
>     engineer to get things done. Now that's MUCH better then XMLC!

>     I think the biggest problem XMLC, JSP and servlets are facing is more of
>     a philosophical nature: the document is data, not code - and Velocity
>     treats it exactly like that. Why would you convert your HTML into a Java
>     class when you want to send it to the browser as text?

>     My 2 cents. Velocity rocks!

>     Bojan
Copyright © 1999-2003, Apache Software Foundation