velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Revusky <>
Subject Re: The Guardian website moves to Velocity
Date Fri, 11 May 2007 19:06:24 GMT
Robert Koberg wrote:
> On Fri, 2007-05-11 at 18:26 +0200, Jonathan Revusky wrote:
>>Robert Koberg wrote:
>>THe templates generated may be simpler, but the overall architecture, a 
>>pipeline of XML->XSLT->VTL->final output is, it seems to me, quite 
>>complex. (Maybe it doesn't seem that way to you, but that would probably 
>>be because you're used to it...)
> I don't 'pipeline' quite that way although that is the sequence, I
> suppose. The pages/templates are pregenerated in our CMS (not all or
> most need to be dynamic at runtime). It doesn't matter what/where the
> runtime is. I have had a preference for Velocity because when I was
> looking for an XML friendly templating syntax in the java world, it was
> limited to Velocity. Maybe someday someone will want our XSL to output
> FreeMarker, just hasn't happened yet.
>>>It would be hard for the interface
>>>type devs to see these in your docs and mentally switch to the XML
>>>syntax, I think. Since I use XSL/XML, it is difficult to transform out
>>>to a non well-formed result.
>>Well, the alternative syntax makes this point moot, but the other deeper 
>>point, I think, is that, once you're using FreeMarker, there isn't that 
>>much reason to use this pipeline of generating a template with XSLT. You 
>>could do everything with FreeMarker, since it is a very powerful XML 
>>transformation tool in its own right. See:
> First, you use a W3 DOM which is very expensive/inefficient. XSL
> processors create a processor optimized DOM. For example saxon creates
> something like a List of SAX events. 

Back in ancient times (early 2003) we used to use Saxon to generate the 
FreeMarker docs. That was using the XSLT docbook project stylesheets 
from Norman Walsh to generate the cooked HTML. (The FM docs are 
maintained in a canonical docbook XML format.)

When FM's XML processing became mature enough, I decided to rewrite our 
docgen stuff using FreeMarker itself. The results were quite amazing, 
and I reported them here.

The FreeMarker docs generation task was about 15x faster than the one 
using Saxon/XSLT. I honestly don't know what the bottleneck in the XSLT 
  stuff was, but these were XSLT stylesheets written as part of the 
docbook project, by a guy who, in principle, really knows this stuff. I 
don't recall what memory usage was. I think I looked, but didn't care so 
much about it, as long as I had enough memory. But IIRC, memory usage 
was also much higher using the XSLT stuff.

That's only one case. We haven't done extensive benchmarks or anything, 
but I remember seeing other people commenting that they were finding 
FreeMarker *much* faster.

> Second, XSL v1 is pretty mature and
> the processors are very good. There are processors for Java, .NET, C,
> Eiffel, and probably others that can use the exact same XSL. 

Okay, that's true enough.

But the idea that the XSLT processors are faster and more efficient is 
not likely to be true, I don't think. The limited data I have (and I 
have no reason to BS you on this) suggest that the truth is 180ยบ away 
from this. FM's XML processing is much faster.

Or maybe the XSLT implementations improved a lot in the last 4 years... 
I dunno... surely not *that* much... My guess is that our project's 
results on docs generation, with FM running 15x faster, that's so 
overwhelming that none of the various XSLT implementations in *any* 
language are likely to be as fast as FM on Java. Even something directly 
coded in C is IMO, not likely to be more than... I dunno... 3x faster, 
which would still leave FM 5x faster. (For that specific benchmark, I 
grant. Maybe it's not typical.)

> My same XSL
> that usually ran on the server can now effectively run on the client
> (for a 'preview' type of thing) for reduced server load. Third, I have
> come to rely on a great deal of the W3 XSL spec, I would hate to switch
> to something does not implement it all. 

Well, yeah, but, of course, FM doesn't implement the W3 XSL spec. But 
isn't that like talking about whether a Pascal compiler implements the 
ANSI C standard? It's a different language...

> Fourth, I have not gone up to
> XSL v2 yet (mainely because of browser rendering), but it wouold be
> relatively painless. Whereas switching to FreeMarker would require *A
> LOT* of work and most likely a lot of feature requests... anyhoo, don't
> want to get off-topic :)
>>Likely, you could replace your:
>>XML->XSLT->VTL->final output
>>to just:
>>XML->FTL->final output.
>>And that truly would be simpler, I'd say. Of course, I told you this 
>>before, and you weren't interested for whatever reason.
> And I told you before, we pregenerate the pages. Think of it like a cache, kinda.

Well, the scheme you describe may have some advantages, probably does. 
But simplicity is not, AFAICS, one of them. (We were talking about the 
advantages of simplicity, weren't we?) I mean, somebody new coming in, 
trying to get their arms around your system, how it all works, for them 
to understand how the XML gets turned into the HTML that somebody sees, 
they have to understand a two-step thing involving two completely 
different tools, right?

Jonathan Revusky
lead developer, FreeMarker project,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message