You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Edmund Urbani <em...@liland.org> on 2004/11/25 15:22:18 UTC
variables&types (new VTL statement, velocity compiler,...)
Hi all!
I've been thinking about ways to improve velocity lately and thought I'd
share some of my ideas here:
It might be very useful to add a new statement to the velocity template
language, to bind its variable to java classes. Consider a statement
#restrict(<javaClass> $variable) with the following semantics:
On all assignments to the variable $variable (after the #restrict
statement) a check is performed, whether this value is an instance of
the specified class. If it is, velocity proceeds normally. If it is not,
an exception/error is thrown.
(So it's actually a somewhat like a variable declaration in Java, except
that you can still use properties and methods only available in
subclasses without explicit class casts.)
I think this would not be fairly easy to implement and it should not
break any existing templates unless someone has defined a macro named
#restrict. So (almost all) current templates would remain unaffected.
Some of the benefits of such a #restrict statement:
- type errors are easier to identify at runtime (exception on
assignment vs. "$variable.missingMethod()" in output)
- some type errors can even be identified at build-time (imagine an
ant-task/maven-plugin performing checks..)
- possible performance improvements, if someone were to complete the
velocity compiler
(btw is anyone currently working on it?)
Naturally, use of this statement would remain optional. It would be the
developer's decision, whether he would write these #restrict( )
statements and have these checks or not. I know, I would want to use
them. What do you think?
Edmund
--
liland open IT solutions GmbH
email: emu@liland.at
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: variables&types (new VTL statement, velocity compiler,...)
Posted by Edmund Urbani <em...@liland.org>.
Will Glass-Husain wrote:
> Hi,
>
> That's an interesting idea. I think it's important that Velocity
> remain a templating language, not a programming language. But that
> idea keeps that approach, just adds additional error-checking for the
> method calls.
>
> You could implement this with a combination of a custom directive and
> a custom Introspector. If you're adventurous, I suggest you try
> playing with these, then submit a patch. If it's helpful, you might
> look at the slides from my talk "Hacking Velocity" at
> http://www.jlamp.com/apachecon
>
> WILL
Actually, I've never messed with Velocity internals/written a custom
directives/introspectors before. So far I just used it - mostly with
turbine. Well, ok, there was that ResourceLoader, I once wrote... hmm,
ok. I'll give it a try this weekend (too busy with other things right
now). It can't be to difficult to do, can it?
Thanks for those slides. I think they'll be very helpful.
Edmund
--
liland open IT solutions GmbH
email: emu@liland.at
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: variables&types (new VTL statement, velocity compiler,...)
Posted by Edmund Urbani <em...@liland.org>.
Will Glass-Husain wrote:
> Hi,
>
> That's an interesting idea. I think it's important that Velocity
> remain a templating language, not a programming language. But that
> idea keeps that approach, just adds additional error-checking for the
> method calls.
>
> You could implement this with a combination of a custom directive and
> a custom Introspector. If you're adventurous, I suggest you try
> playing with these, then submit a patch. If it's helpful, you might
> look at the slides from my talk "Hacking Velocity" at
> http://www.jlamp.com/apachecon
>
> WILL
I've been looking at the velocity developer docs and API. I agree, that
a custom directive would be needed to store the variable restriction
data. But I don't see how a custom introspector would help me with the
checks. Assignments are performed by the #set and #foreach directives
and I found no way to alter their behaviour and add additional checks
(ie. other than modifying velocity source). I also looked at the event
handlers, but there's only one for assignments with null values.
Edmund
--
liland open IT solutions GmbH
email: emu@liland.at
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: variables&types (new VTL statement, velocity compiler,...)
Posted by Will Glass-Husain <wg...@forio.com>.
Hi,
That's an interesting idea. I think it's important that Velocity remain a
templating language, not a programming language. But that idea keeps that
approach, just adds additional error-checking for the method calls.
You could implement this with a combination of a custom directive and a
custom Introspector. If you're adventurous, I suggest you try playing with
these, then submit a patch. If it's helpful, you might look at the slides
from my talk "Hacking Velocity" at
http://www.jlamp.com/apachecon
WILL
----- Original Message -----
From: "Edmund Urbani" <em...@liland.org>
To: <ve...@jakarta.apache.org>
Sent: Thursday, November 25, 2004 6:22 AM
Subject: variables&types (new VTL statement, velocity compiler,...)
>
> Hi all!
>
> I've been thinking about ways to improve velocity lately and thought I'd
> share some of my ideas here:
> It might be very useful to add a new statement to the velocity template
> language, to bind its variable to java classes. Consider a statement
> #restrict(<javaClass> $variable) with the following semantics:
> On all assignments to the variable $variable (after the #restrict
> statement) a check is performed, whether this value is an instance of the
> specified class. If it is, velocity proceeds normally. If it is not, an
> exception/error is thrown.
> (So it's actually a somewhat like a variable declaration in Java, except
> that you can still use properties and methods only available in subclasses
> without explicit class casts.)
>
> I think this would not be fairly easy to implement and it should not break
> any existing templates unless someone has defined a macro named #restrict.
> So (almost all) current templates would remain unaffected.
>
> Some of the benefits of such a #restrict statement:
> - type errors are easier to identify at runtime (exception on assignment
> vs. "$variable.missingMethod()" in output)
> - some type errors can even be identified at build-time (imagine an
> ant-task/maven-plugin performing checks..)
> - possible performance improvements, if someone were to complete the
> velocity compiler
> (btw is anyone currently working on it?)
>
> Naturally, use of this statement would remain optional. It would be the
> developer's decision, whether he would write these #restrict( ) statements
> and have these checks or not. I know, I would want to use them. What do
> you think?
>
> Edmund
>
> --
> liland open IT solutions GmbH
>
> email: emu@liland.at
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org