velocity-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Will Glass-Husain" <>
Subject Re: EscapeTool (and velocity-tool best practices)
Date Thu, 09 Dec 2004 17:38:17 GMT
I like this too.  It seems the most intuitive to me, particularly (as Nathan 
says) that the types of references are not explicit in Velocity.

To carry this further, I've proposed previously that the "==" operator have 
a fallback to toString equality.  In other words if the user does
#if ($a == $b)

If a and b are the same class, it should call equals(), but otherwise it 
should call toString.equals().  I've found this useful in JSTL, where I have 
a class that implements a singleton enumerated type.  In the JSTL I can say
  <c:if test="${status == 'Active'}">

Even though status is actually a singleton class StatusActive with a 
toString 'Active'.

Obviously, this would be a Velocity 2.0 change.  In the meantime having 
tools accept an Object parameter seems like a good solution.


----- Original Message ----- 
From: "Nathan Bubna" <>
To: "Velocity Users List" <>
Sent: Wednesday, December 08, 2004 5:02 PM
Subject: Re: EscapeTool (and velocity-tool best practices)

> On Wed, 08 Dec 2004 15:21:34 -0500, Mike Kienenberger
> <> wrote:
> ...
>> In general, should Velocity tools that operate on a String operate on an
>> Object instead and perform a object.toString() conversion first?  Or at
>> least provide Object argument wrapper methods to call the String argument
>> methods?
> ...
> in general, yes.   the type of VTL references is a) not obvious, b)
> mutable, and c) not as important as its string representation (since
> we're working with the ''V" in MVC here).  as such, it's usually a
> good idea to accept Objects and then attempt conversion to the needed
> type.  if the param is null or the conversion can't be made, then it
> is usually considered best to return null rather than throw
> exceptions.
> these aren't hard and fast rules, but they've worked very well for me.
> and they are what i prefer when it comes to contributions/patches.
> ;-)
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message