velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Robert Edgar" <>
Subject RE: Dynamic Nested Templates -Don't Agree that this is not what Velo is for
Date Sun, 11 Nov 2001 04:39:20 GMT
Thanks Geir,
By fixed I think what I meant was, refering to your example below, that the
BODY template was a static reference.

I hadnt thought of using variables for templates names.

Also fixed in that the body template is one template whereas we might have 4
template that together constitute the body for pageX, I know you could just
use another template to aggregate those template but it just looked like
more and more files whereas the beauty of the XSLT approach is one single
file can aggregate templates for the body and also aggregate templates for
the leftnav, rightnav etc.

Also taking your example the frame page for us would just be another generic
template rather than specific to a page, with XSLT essentialy I can say "use
template1 and within template1 replace the leftnav with the content of tpl2,
tpl3 and tpl4"
and on the next call say  "use template1 and within template1 replace the
leftnav with the content of tpl5, tpl6". Template assembly or aggregation
becomes very dynamic.

Velocity can do this AFAIK ... just wasnt obvious at first glance.... XSLT
is beautiful and easy to use, and the only reason we are now looking at
Velocity is that we are moving to using a caching technology and each page
will use Edge Side Includes(ESI) to generate the trully dynamic content and
the rest of the page is now static html templates so we want to use a system
to pregenerate these static html templates from a collection of
sub-templates retaining XSLT to be accessed by the ESI for generating
dynamic content on the fly.


-----Original Message-----
From: Geir Magnusson Jr. []
Sent: Sunday, November 11, 2001 10:59 AM
Subject: Re: Dynamic Nested Templates -Don't Agree that this is not what
Velo is for

On 11/10/01 9:05 PM, "Robert Edgar" <> wrote:

> Guys,
> Maybe I didn't explain myself clearly, my fault!
> No problem, anyway here is my "take" on things.
> I understand that Velocity is a templating engine, we are currently using
> XSL as our templating engine, I have a standard "template" which is a
> XSL stylesheet, actually I have several "standard" templates covering
> different sorts of pages that I have on my web site. Within a standard
> template I then load sub-templates to format different sections, so on my
> site home page I have the main page template and sub templates for a
> on latest news .

So far so good.  This is the kind of thing you can do with #parse(), for

> Now to me this is EXACTLY what velocity is about.
> The only issue I had here was that Velocity "seemed" to require a template
> to be fixed rather than dynamic in that although it can have nested
> templates,

What do you mean 'fixed'?

A common technique is to setup a 'frame' or 'layout' that positions the
parts of the page, such as the top, nav section, footer, and body, and then
you use references to setup all the parts.... Something like

   <td colspan=2>
       #parse( $header )
       #parse( $leftnav )
       #parse( $body )
    <td colspan=2>

And then the servlet choose the $header, $leftnav, $body and $footer based
on user and current context of the app.

Just one approach among many...

> using the #parse directive, these are preset in the template
> whereas I wanted something dynamic in that a template will display a VAR
> a point in the template but I want the VAR to be the output of #parse some
> previous template.

#parse() can take references, so the actual thing can be chose independently
of the framing/layout tempalte
> After looking a bit father myself it "seems" to me my "standard" templates
> can be loaded as Velocity Macro's in the form of the global library.


> My
> understanding is that a Macro is called and is passed parameters which can
> be anything including the rendered output of another template. If that is
> the case that almost exactly matches an XSL call-template directive.

Sure.  You can do something like

#set($templateoutput = "#parse($foo)")

#myvelocimacro( $templateoutput )

(note the " in the #set() )

> So ....  correct me if I am wrong .... but to me this is exactly what Velo
> is about and it can do what I want...

Then switch as fast as you can :)

I like XSL but I think it's really challenging for the view layer :)


Geir Magnusson Jr.
System and Software Consulting
"Whoever would overthrow the liberty of a nation must begin by subduing the
freeness of speech." - Benjamin Franklin

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

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

View raw message