velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <ge...@optonline.net>
Subject Re: Velocity Jar File Size...will it get smaller?
Date Mon, 12 Feb 2001 11:30:29 GMT
mike@bodaro.com wrote:
> 
> The template language syntax appears to be exactly the same.
> 
> Can you tell me the architectural differences?

While the language syntax is very close but not exactly the same.   The
syntaxes were kept close for a few reasons :

1) The syntactical approach of $<foo> for references and #<bar> for
directives is a good one! It's easy for designers to work with, people
understand it, and there was no reason to reinvent the wheel.
2) Since so many people were using the syntax, why invent another one? 
Also, it makes the Webmacro to Velocity conversion much easier :) We
even have a tool to help with that.

Velocity was built new from the ground up.  There isn't a snippet of
shared code.

Architecturally, the biggest difference until recently was the parser. 
The Velocity parser is written using a tool called javacc, a very
popular Java-based parser generator.  I believe that it originally came
from Sun, and is now maintained and managed by a company called Metamata
: www.metamata.com.  

The WebMacro parser was written by hand I believe until recently - their
new parser, for thir 0.95 release is also written using javacc.

I can't tell you fundamentally how WebMacro is built - I have never
reviewed much of the codebase.  

Velocity is very simple in its architecture, as it is meant to be
nothing more than a template engine. The idea is to do one thing only
and do it well.  Much in the spirit of the Unix philosophy - have a good
set of simple tools, and create bigger things using them.

It was recognized that it wasn't going to try to be a 'development
framework' - there are plenty around, such as Turbine.  

Therefore, all facilities like 'context tool' and other resource
management are purposely left out of Velocity, acknowledging that not
only will frameworks do it, they will do it better anyway.  Futher, by
leaving out of the Velocity core much that should be done at the
application / user / framework level, the Velocity core remains smaller
and therefore, in my opinion, more maintainable.

The only resource management that velocity will do for you is related to
file-base templates.  This was recognized as the way 99.9% of velocity
users will use Velocity, so effort was made to do efficient file-based
template management.  Velocity will cache parsed templates, and will
access that cache on subsequent getTemplate() calls or #parse()
directives, as well as cache non-parsable resources for efficiency in
the #include() directive.  There are ways to use other template sources,
or even create templates dynamically.  And the resource system is
extendable - if you have a special need, you can always write a new kind
of template loader and use it - it just plugs right in.

Internally, it's pretty straightforward.  There are no threads created
or managed for you.  Templates are parsed and caches, kept in their
internal form of an 'Abstract Syntax Tree', a tree structure that is
then rapidly walked when your template is merged.  Each node corresponds
to on of the syntactical elements in your template.

The template merge process is threadsafe, ensuring that there will be no
problems in a multithreaded environement like a servlet container

The biggest feature difference between the two are the 'Velocimacros',
something you should take a look at.  I won't attempt to describe here.
:)

I hope this helps.  The best way to understand velocity is to use it,
and of course nothing beats looking at the source code.  

Keep the questions coming!

geir

> Mike Papper
> 
> >>>>>>>>>>>>>>>>>> Original Message
<<<<<<<<<<<<<<<<<<
> 
> On 2/12/2001, 12:00:34 AM, Jon Stevens <jon@latchkey.com> wrote regarding
> Re: Velocity Jar File Size...will it get smaller?:
> 
> > on 2/11/01 10:47 PM, "mike@bodaro.com" <mike@bodaro.com> wrote:
> 
> > > I noticed that the WebMacro jar is about 350Kb too.
> 
> > Velocity != Webmacro.
> 
> > They don't share *any* source code.
> 
> > -jon
> 
> > --
> > If you come from a Perl or PHP background, JSP is a way to take
> > your pain to new levels. --Anonymous
> > <http://jakarta.apache.org/velocity/> && <http://java.apache.org/turbine/>

-- 
Geir Magnusson Jr.                               geirm@optonline.com
Velocity : it's not just a good idea. It should be the law.
http://jakarta.apache.org/velocity

Mime
View raw message