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:
http://freemarker.sourceforge.net/docs/xgui_declarative_basics.html
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.
http://www.theserverside.com/news/thread.tss?thread_id=20015
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, http://freemarker.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
