I am not sure but beans typically use instances, one of the contracts for a javabean
is that it has a no-argument constructor. statics should always be avoided. almost
100% of the time.
ian
u, Nov 20, 2003 at 05:40:34PM +0200, Taavi Tiirik wrote:
I am about to use this #bean macro and am
Hmm, it seems that $!webwork.htmlEncode() is doing exactly
what I was looking for.
taavi.
I am about to use this #bean macro and am wondering if
this is a proper way of doing it?
My .vm page contains:
#bean( util.Html $html )
$html.escape( This text will bend up escaped/b. )
and my
I've opted to move this to the webwork extensions rather than have it
part of the webwork core. Although the VelocityServlet will be
deprecated, that won't be til Velocity 1.5!
One of the features that's extremely appealing about the velocity tool
project is the ability to easily add your own
I totally agree about putting it in webwork extensions!
Jonas
Matt Ho wrote:
I've opted to move this to the webwork extensions rather than have it
part of the webwork core. Although the VelocityServlet will be
deprecated, that won't be til Velocity 1.5!
One of the features that's extremely
Matt Ho wrote:
I've opted to move this to the webwork extensions rather than have it
part of the webwork core. Although the VelocityServlet will be
deprecated, that won't be til Velocity 1.5!
One of the features that's extremely appealing about the velocity tool
project is the ability to
, November 18, 2003 11:42 AM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] velocity tool support
I totally agree about putting it in webwork extensions!
Jonas
Matt Ho wrote:
I've opted to move this to the webwork extensions rather
than have it
part of the webwork core. Although
I agree, and having just refactored these bits in ww1 I think that
adding all this velocity config stuff to webwork is duplication and
unnecessary. The jsp equivalent for example would be to suddenly allow
for the ability to define various scoped objects in the webwork config.
Use a
