Cedric has started a discussion on the future of Velocity, and has put out a new templating solution, Canvas, which builds on the Groovy language. Canvas has the simple Velocity API that we are used too, yet gives you the power of Groovy in the templates themselves.

Should templates have this power? or should they not allow you to "code" in them?

If you look at Canvas code, it looks more like JSP than Velocity in many ways:

<%
data = ["Cedric": "San Francisco", "Alois": "Paris"]
result = ""
for (e in data) {
  result += ("${e.key} lives in ${e.value}\n")
}
result
%>

Canvas home page

Cedric on Canvas: a Velocity killer

Groovy is a cool language but do we really need or want that level of power in a template language? I don't think so. Everyone talks about how bad JSP scriptlets well this is just another way of breaking the dividision of responsibility in an MVC environment.

Rob

I do not think it is a velocity killer, but it can be usefull for some use cases like custom templates for code generation tools, it must be more easy
to customise script than to implement/extend tool API just to define some variable.

Although you see some JSP-ish syntax here, that doesn't mean it has to be like that. I think it would be powerful to support Velocity-ish syntax, as well as others (Zope-like has been mentioned).

One of the powerful features of this approach (as well as Velocity of course) is that the templating is in a unit of its own... and not tied to anything (e.g. JSP is coupled to the web tier, you don't see many people creating .jsp files for general text generation).

The larger picture for me is the marriage of Java + Scripting / Higher level language. For example, within the TSS codebase you can choose to write a particular component as Foo.java or Foo.groovy. There is a time and a place for choosing one over the other. This is pretty powerful IMO.

Dion

Just wondering if anybody uses StringTemplate available at
http://www.antlr.org/stringtemplate/index.tml

There is also a nice paper (also on the same page) regarding enforcing separation of views and logic without sacrificing power.

Joe

I think many of the posts on the log capture the following:

Velocity seems to provide a very definite philosophy on the demarcation between display logic and business logic. Pushing the emphasis onto display logic; velocity does not encourage you to place logic in the template and encourges the developer to place intelligent objects in the session.

IMHO this tends to encourage a clearer demarcation

I am not saying that above is not useful I just feel it's not directly comparable I'd compare the above to JSPs; which do not encourage intelligent session objects as much.

Nice to see groovy in action; what a sexy langauge ;-)

Its strange to hear you say that Velocity is an almost dead project - there seems to have been a fair amount of activity on the dev list. If it turns that no-one wants to maintain in then I certainly will.

The logging thing is a point that has been done to death on the Velocity dev list. I am personally against the way in which Velocity preforms its logging but the commiters think otherwise - what can you do.

Certainly Velocity has its flaws but let's not start a new solution when a perfectly good one exists that could be extended. With a bit of work it would be possible to strip out the Velocity logging tools and replace it with something better and add better control of the indentation and formatting of output.

One major benefit of Velocity is that the language is so simple - it is an ideal solution for split development responsibility between Java developers and HTML coders.

Rob

It looks like every other Java-web-framework out there, Canvas focuses solely on getting data out of the application to the web. Where I would want more help is getting data in from the web to my application. Or even better: Databinding. I think it's a good thing to see more applications of groovy, though!

Johannes, you've succintly pointed out the problem inherent in most of these web frameworks. If you're interested in a framework that provides much more help on, as you said, getting data into your app through options like data binding take at look at NEFS at http://www.netspective.com. It's available as open source, too.

No offence Shahid but that was a really overt sales pitch.

http://www.hormel.com/templates/brands/brands.asp?id=12&catitemid=78

Regards
Neil

What do people feel about Freemarker? It seems to be a fairly active project, the functionality seems pretty comprehensive, and there is a clean separation between presentation and logic. Yet, I never see much endorsement on TSS...how come?

I tried to use FreeMaker but its language is not powerful enough, so I end up with using Xalan's scripted XSLT extension and used Jython as scripting language.

I've used velocity for ww.abclinuxu.cz first, but there were many annoying issues with it (like parameter passing by names!) and the project seemed dead (Geir was not able to rename RC-release to final for many months). So I switched to Freemarker.

It is much more powerfull and fits my project well. Velocity symptoms appeared theer too (development stopped for many months), but actually it got a momentum again. I am looking forward for 2.3 release.

IMHO Freemarker is better designed and supercedes Velocity from technical point of view.

I think that one aspect is "visibility". Since Velocity is part of Jakarta it gains much more visibility and popularity. Obviously FreeMarker doesn't have this "Jakarta-Bonus".

It's interesting that we happy users of Freemarker aren't as vocal as some of the Jakarta Velocity (and other alternative templating language) users. I have found FreeMarker to be very well designed, and with a single .JAR file, it's a piece of cake to integrate. Freemarker has built-in support for templating on web engines but it works equally well on non-web-based applications that need templating too. IMHO, it's a very underated templating library and anyone who uses Velocity and is unhappy with Velocity's development progress should give FreeMarker a try. Having used FreeMarker for some time (on systems with hundreds of templates) I would recommend it over most of the Java-based templating engines out there.

* pro velocity:
+ does not need to be compiled, can easily be stored in database
+ on many servlet engines it is (said to be) faster than JSP

* pro JSP:
+ through Taglibs you get MUCH cleaner code, even pure XML representation is possible (however some prefer brevity over clean code, which is okay, but i am not one of those people)
+ it's a standard, AFAIK this results in much better tool support, better maintainability, portability, no uncertain future etc.

cheers
joe

for me the most important pro of velocity is that you can use it independantly of the web. For instance you can use it to create sophisticated emails, also it allows you to use the more sophisticated features of hibernate like lazy loading collections for which an open connection to the database is required.
I know there are hacks to do the same with jsp views such as the "Open Session in View" pattern but that has some serious problems

That's, of course, assuming that we understand the underlying
technology that makes taglibs (and JSTL and JSF) work and are
aware of the incurring costs.

It looked to me that we already have a number of view technologies:
XSLT (static transformations or dynamic pipelines with Coocon),
templating engines (WebMacro, Velocity, and many commercial ones),
XMLC (a distinct technology to create and populate XML documents with
data), Jython,.. There are also packages that allow to integrate
TCL with Java for presentation and rich GUIs, quite powerful too.
But... I guess it's good that our developer community has such rich
choice of tools, libraries, technologies.

The first idea on developing velocity, was to cut off power from JSPs,
with this "Canvas" you`ll have even more power than in JSP

is this an smart idea??

PS.: can some one in BEA give Cedric some thing to do??

>with this "Canvas" you`ll have even more power than in JSP is this an smart idea??

Yes, the idea is smart.
Power should not be limited: it should be conveniently controlled. We probably want to limit power in hands of idiots, but cutting off abilities for smart people does more harm then good.
I believe that we are witnessing shrinking IT force that meant more professionals and less people after “Programming in 24 hours for Dummies” courses working in the field. So, those professional demand power tools…

You are obviously much more fortunate than I.

I have found it easier to write a bad JSP than a bad velocity script. And most people I've worked with (myself included manytimes) just do the easy solution. Deadlines, work pressures and a 'just do it' atmosphere encourage such behaviour.

If you're surrounded by concientious coders _cool!_ all the better; personally I need a little encouragement at times to do the right thing.

Yeah, so basically idiots will use Velocity, smarter people will go with JSP, and geniuses will run on Canvas ! :)
Guess I'll just stick with Velocity. There IS a reason why templating languages should have certain limits: code in template is a Bad Thing (tm). Because smart people write business logic, not templates. Because logic can be reused in different templates, instead of breaking the templates in myriad of unmaitainable macros, and so on. Old debate, you know ? (http://jakarta.apache.org/velocity/ymtd/ymtd.html)

Idiot by choice

Nope, smart people will just use right tool for the right job. Being big fan of Velocity I ran into situations when I had to create classes to handle presentation logic.

>>There IS a reason why templating languages should have certain limits
Absolutely agree. It looks like those limits are yet to be defined.

>> templates in myriad of unmaitainable macros, and so on.
Same holds true with classes.

I understand your feeling because there are so many people abuse and misuse power, but lets separate technical aspects from emotional.

I hope you do not want to prohibit cars just because there are drunk drivers.

I just posted the following on my weblog (where you will get a better formatting and links :-)).

==

I have to say I am surprised by some of the comments I have received about Canvas, and in particular from people who say that the Velocity Template Language (VTL) is a better choice than Groovy because it's not a "real" language, so you are not tempted to mix presentation and business logic.

First of all, the assumption that the generated template is for "presentation" (probably meaning: a Web page) is a generalization. Velocity is used for much more than just generating Web pages, so this argument is weak in my opinion.

But if you think the VTL is just a declarative language, you are fooling yourself. VTL has

    * Control structures (if, while, etc...).
    * Variables.
    * Macros.
    * And worst (or best) of all, it has access to the underlying Java objects.

In other words, I am pretty sure that you can use VTL to write arbitrarily complex pieces of code inside your template, and Sam was quick to point out a perfect example of that.

With that in mind, if we are going to have to deal with a language inside the template, I would rather use one that I like, is powerful and ideally, close to the Java syntax.

There is also another reason why VTL is less than optimal for this, and it has to do with the philosophy behind Velocity templates.

Velocity templates make no distinction between "verbatim text" and VTL. The only way to identify the pieces of VTL code in your template is by spotting the various syntactic annotations (#, $, etc...). The problem with this approach is that it makes it pretty much impossible to guarantee the indentation of the generated files, since you can never tell when a space is significant (part or your "verbatim text") or should be ignored (used to indent a VTL expression).

The JSP syntax (or any delimiter-based syntax) makes it obvious what spaces should be preserved and which ones can be ignored for the generation of the final file:

    // Canvas template
    public class GeneratedClass {
      <%
        for (i in methods) { i.generate() }
      %>
    }

From my experience, it is absolutely impossible to get a decent indentation for this very simple example with Velocity...

--
Cedric

>
> // Canvas template
> public class GeneratedClass {
> <%
> for (i in methods) { i.generate() }
> %>
> }
>

This syntax was invented by ASP for language independant preprocessor, not for
indentation.
Velocity syntax is html frienly (you can edit html and view template in browser without server and recompilation)
There is nothing bad in Velocity syntax, it is just too limited for some use cases, like RTF text or your example. It is possible to solve with "arious syntactic annotations" like Visual Basic syntax
line_
line

> From my experience, it is absolutely impossible to get a decent indentation for this very simple example with Velocity...
>
> --
> Cedric

Konstantin, were you ever been fined for using JSP while programming :)

>I hope you do not want to prohibit cars just because there are drunk drivers.
Nope, but progress is being made.
http://www.bris.ac.uk/research/ip/business/sci_eng/drive.html

The problem in your reasoning is that there is no "right tool for the right job", but more of a "right tool for a specific job done by a certain person". While I may be very/too relaxed on choices in my own green-field mini-projects, I tend to choose more stable and error-proof technologies when working in big teams on serious apps. Not because I disconsider my team-mates ! Let's just say it's a matter of playing it safe.

Besides, there's a HUGE difference between a drunk driving a Hummer and a drunk driving a Trabant.

Exactly!
And you seem to look in the right direction, at least that link points to a device that prohibits certain persons from driving :).

>> Besides, there's a HUGE difference between a drunk driving a Hummer and a drunk driving a Trabant.
Hmm, I am confused: do you try to say that we all should drive Trabants?!

As more real applications get web interfaces, the need for presentation beyond simple templating grows. A template + beans is fine for pushing content from a database or branding the look and feel of a simple form, but when you have more complex functionality, including changing security contraints, dynamic page generation, and interactive content, you need more power. There is still a need to separate presentation from functionality, but you need the ability to code the presentation, not just include a banner or tabular data.

So what kind of license does Canvas have? I see the classes are in the com.bea.* namespace :) Can I use this in my project?

 S.

> So what kind of license does Canvas have? I see the classes are in the com.bea.* namespace :) Can I use this in my project?

We're working on that, it will probably be Apache.

If you are uncomfortable with the current lack of license, steal the source, rename a few methods and make them yours. It's only three classes after all. But you can't call it Canvas. And you owe me a beer.

--
Cedric

Cedric, I love it! Canvas is hereby nominated to:

Most simple product EVER!
(Never has so little code done so much for so many)

Only one point. You should rename the example file template1.canvas to template1.html of course it doesn't matter but still..

Regards
Rolf Tollerud

Rolf:
Only one point. You should rename the example file template1.canvas to template1.html of course it doesn't matter but still..

Why? Why do you think it's an HTML file?

It's really funny to see everyone assume that a template framework will be used exclusively to generate HTML pages...

--
Cedric
http://beust.com/weblog

Cedric: "Why do you think it's an HTML file?"

Rolf: "Have I said that it is an html file?

I said: "it doesn't matter"

But the main use still will be html templates..
And when you give the file to the designers it is practical to just double-click it..
You confuse newbie’s..

To accent "off far out use" == typical of Unix nerds.
Not to care 2c for beginners == typical of Unix nerds.

I know already what you will say!
"Oh, it is so normal and common to parse all kinds of non-html files I do it dozen of times every day!".

Spare me.

Regards
Rolf Tollerud
(Great God)

I used/currently using Velocity not just for HTML files but also for generating :
- XSL-FO files
- complex XML files which would be a royal paing to generate via other (castor, xmlbeans, etc.) means
- Hibernate mapping files
- source code (mainly Java)

While Velocity does not forbid intricate logic constructs inside the templates, it surely makes it rather difficult (compared to Canvas). This is the reason why the vast majority of templates have rather simple loops, rudimentary conditional statements and just a few method calls inside. This makes the templates :
a) readable
b) maintainable
even by non-programmers (the guy responsible with FO stuff was a complete Java newbie !)

I think that a flexible 'templating' engine like Canvas would certainly speed up the initial development BUT with the price of increasing system fragility. While Groovy is definitely cool and I have already used it in production code in my company, while Canvas is clearly a neat toy, Velocity will still be my favourite templating tool.

Geir, kudos to you and the Velocity team for a great project.

http://www.cheetahtemplate.org/

Unfortunately it's for Python. Anyone interested in porting it to Java?

>
> Unfortunately it's for Python. Anyone interested in porting it to Java?

Incidentally Sam has recently committed a template engine API together with a simple template engine implementation (in 1 class!:) into the current Groovy codebase which appears to be similar to both Canvas and Cheetah in functionality. i.e. using JSP EL style expressions (which are really GPath expressions) together with ASP/JSP expressions & statements.

One thing about template engines is that there's not always one size fits all. Some folks prefer Velocity / WebMacro style #directives, some prefer ASP/JSP style <% %> notation, some like the new JSP 2.x style custom tags + JSP EL and some like Zope style TAL template engines where mock data can be included inside normal HTML using special attributes (a bit like Tapestry too).

Hopefully we'll be able to provide a few different template engine implementations (which derive from TemplateEngine) to suit different tastes and requirements - e.g. a velocity-style, JSP style and Zope style template engines.

James
Core Developers Network

Well yes, Tapestry 'templating' is a good example. It is conceived for web programming, thus completely transparent for web designers. It has very limited procedural constructs (@Foreach, @Conditional) thus making quite difficult to include complex logic inside the template. In a certain way, it gently pushes you to 'do the right thing' : write your logic in the classes (components, beans, etc.) ! It comes as a natural thing to do in Tapestry...

I have extensively used Cheetah in a project (about 30 different templates) in one of my previous projects (to generate Java classes and various descriptors starting from a given database instance). These templates were conceived and modified quite often on a YAGNI basis. Funny thing, I have noticed that the vast majority of the templates were really simple constructs, nothing really advanced which would involve extreme VTL perversion into a hypothetical Velocity porting. The only real advantage was zero build cycle for Python scripts, very convenient for debugging and adhoc improvements.

It's nothing compared to us cleanshaven postmodern english writers.
I was using Velocity before, but will now switch to Canvas, with my book,

"The use of semicolon in the works of Jane Austen"

Eric Raymond: The Luxury of Ignorance

Regards
Rolf Tollerud

While the lead is misleading ("Cedric has started a discussion about the future of Velocity..."), as if Cedric as anything to do with the future of Velocity ;) I think that it's great that people still refuse to just use the 'standard' and keep working to find new and innovative solutions to the problem of the view layer in the web, and if, like Velocity and others like it, they can be used outside of the web environment, even better. (I actually think it should be required...)

As one of the developers of Velocity, I naturally am proud of the project and it's community, and would like to offer corrections to some of the inaccuraces regarding Velocity stated in the blog.

First, it's not in any way a dead project - there was a quiet period for a while (ok, a long while...), but things are back and moving, with the v1.4 being released this week, 1.5 going into rc status, 1.6 is mapped out including well-tested patches waiting for application. There even are plans for a v2.0, the version we want to use to make some corrections that are backwards compatbile. Further, the tools 'subproject', which provides excellent tools for use w/ Velocity as well as the necessary bits to use Velocity as the view layer in Struts, is also alive and well.

Second, there is no log4j dependency unless you want to actually use log4j as your logger. We try to discover it in the classpath and use it, but don't require it. (Or shouldn't - if it does, it's a bug).

The Velocity logger is pluggable, so you aren't tied to any one logging solution, and we are currently working on how to redo the internal logging of Velocity to improve the information given to users, and to help the tools subproject integrate log streams in a better way. Yes, there's a commons-collections dependency - we started the codebase w/ a contribution from Velocity way back, and felt we should eat our own dog food.

Finally, the indentation issue is probably the oldest unresolved thread in Velocity history, and one that honorable people disagree on. There is a fundamental 'tug of war' between 'pretty templates' and 'pretty output', a result of wanting to respect every character in the template (it is a template after all, not a program) and it comes down to whitespace handling.

It's a templating system, so it outputs every character that isn't a directive (#foreach) or a reference ($i). It doesn't divine the intention of the author, saying "hey, this is Java code I'm outputting, so I'll make it pretty...". If we could write code like that, we would. Most people solve it pretty simply with a language specific pretty printer. However, (being not a dead project) it's still a ongoing issue of discussion.

One final note, my contribution to Canvas : drop the requirement for the class Context. Use a Map, since that is what you really want anyway. It will be far more flexible for users, and it gets the codebase down to 2 classes. :)

geir

One reason why I like Velocity is that it is so performant. I believe that it is down to the fact that it is so single minded in what it does - it does one thing very, very well.

It looks like Canvas is pretty powerful, but what kind of performance penalty are we going to pay?

>
> It looks like Canvas is pretty powerful, but what kind of performance penalty are we going to pay?

Canvas & the template engine inside Groovy CVS HEAD both convert the template to a groovy script which gets compiled to bytecode so performance (eventually) should be fine.

James
Core Developers Network

//Canvas & the template engine inside Groovy CVS HEAD both convert the template to a groovy script which gets compiled to bytecode so performance (eventually) should be fine.//

I was experimenting with different HTML rendering technologies some time ago and I have created Velocity based and JSP based versions of the same UI, guess what? Velocity version performed about 30% better than JSP( no, it was not because of JSP compilation time ).

I use JSP scriptlet as my template language, making tag include these JSP,
it work well.
I don't want to learn some else language,because scriptlet is enough.Dividing
logic into seperately part is your responsibility , not the language.
On the other hand, JSP can compile automatically, it's java code after compiling, so, it is fast than any complex interpret engine.

Yes - its not just used for HTML. I use it for xml files, sql statements and scripts.

Right on Leon.

The problem with Velocity is it is only usable from java code.

XML can be generated by any language, and XSLT can be processed from any language.

That has a nicer 'smell' than something javacentric.

True, but the nice thing about Velocity is that it is not limited to 'just' XML. I'm using Velocity to create RTF documents. That's something you could do in XML/XSLT too, but why bother wrapping your data in another dataformat when you can just use the raw data as a base for your documents?

A problem with XML/XSLT is, IMHO, that it is NOT Java centric. Using XSLT extensions you can have all the Java functionality you could wish for during XSLT processing, but it is not something that can be universally used on every XML parser/XSLT processor combination.

t looks like every other Java-web-framework out there.