Dear velocity,
I am new too to velocity. I have been playing with it over the last
few days. Also I like it, it seems to miss one functionality which is
critical to my needs.
This is something I use in my own mini template system but don't know
how to handle with velocity.
I am wondering if this functionality makes sense to you and if there
is some interest to support something similar.
Basically I would like to be able to include nested template inside a template
but with a finer control than a #include statement.
I believe this would be useful to render tree-like structure of objects
containing templates which should be nested with each other in the
final output.
Velocity offers a kind of a switch statement, something like:
#if ($display == 1)
#include template1
#else if ($display == 2)
#include template2
...
Nothing wrong with this code except that first it hardcode some of the display
logic in the template rather than in the object, and second more
importantly it hardcode the display switch of a sub-element of a page
inside the parent node. Ideally the parent node should let its
sub-element decide for itself.
In fact what I would like to do is to remove the logic from the
template all together and in place give the control back to the
calling object.
Something where template1 start to be processed up to some point, then
give back the control to the calling object which might decide to
include template2 and finally finish the processing of template1.
Following is a typical example where I think this approach makes sense:
Let say we have two java objects describing respectively the body of a
document and the navigation element. The two objects are part of a
tree structure describing a web page, the navigation element being a
child node of the body element.
These two elements manage their respective data and decide
independently to render themselve one way or another using different
templates. For exemple the body might decide to position the
navigation on the left or on the right according to user preferences,
and the navigation might decide to expend itself to the admin
navigation or to a default menu according to user privileges.
In this example the body would have two templates available (for the
navigation on the left or on the right), and the navigation would also
have two templates available for an anonymous user or a power user
(default menu or admin one).
Following would be the structure of the body templates:
-------------------------------
<BODY>
some html
#subnode ("navigation")
some html
#subnode ("contentArea")
some html
</BODY>
------------------------------
and this is how the body object would uses the template:
(let assume that
'bodyTpl' is a reference to the previous body template
and 'nav' is a reference to the navigation node object).
public void write (StringBuffer out)
{
String nodeName;
bodyTpl.init ();
while (bodyTpl.hasMoreElements) {
nodeName = bodyTpl.renderPart (out);
if (nodeName.equals ("navigation")) nav.write (out);
if (nodeName.equals ("contentArea")) content.write (out);
}
}
The main advantage between this approach and an 'include' directly in
the body template is that the body element does not hardcode any logic
about the navigation element, nor in the template, nor in the code.
This allow a true separation of responsibilities and make elements
really plugable. The only thing that the body knows is that it should
be a navigation keyword somewhere in its template and that when it encounters
it, it should pass the control to its navigation node. Then it is up
to the navigation node to decide which of its own templates it should
use to render the query.
Finally when the navigation element has finish processing, the control
goes back up the tree structure to the body node
which complete the rendering of its template.
This is how my mini template engine work. Also I like this
behavior, it does not support #if #else statement, nor #foreach,
nor anything like $user.getFirstName ()...
So wouldn't mind to give Velocity a go.
Regards.
Olivier.
----------------------------------------------------------------------
Olivier Louchart-Fletcher
Email: [EMAIL PROTECTED]
