Velocity itself has a rule to accept all public methods. It is up to
the programmer to decide which methods to make available to Velocity
by making the methods public. Velocity, even JAVA, has no way of
knowing if a method will change the underlying class. Making a class
immutable is up to the programmer.
You could extend the underlying class, override the setter methods
to do nothing, and pass this class to Velocity.
public class MyImmutableClass extends MyClass {
public MyImmutableClass(MyClass clazz) {
this=clazz;
}
//Override setter methods and any other methods that
//change the underlying class to do nothing
public void setField(Object o) {
}
}
Then for Velocity:
MyClass clazz=new MyClass(...);
//Make changes to clazz
ctx.put("clazz",new MyImmutableClass(clazz));
//Now template designer cannot change clazz but can access all
//other methods
--------------------------------------------------------------
Whenever possible, I try to design classes from the start as immutable
classes, following best practices. Have a constructor that gets all
the information and then don't have any methods that would change it.
This is not always convenient or possible, but can happen more often
than you might think if you are creative.
If you are creating objects from scratch that will be passed to
Velocity, it is good to create them as immutable objects. Otherwise,
it is relatively easy to add a boolean field that is checked before
executing methods that would change the underlying object. Then have a
method or constructor that provides a version of the underlying class
with this boolean field set to false. Pass this immutable version of
the class to the Velocity context.
--------------------------------------------------------------
Barbara Baughman
X2157
On Fri, 11 Feb 2005, Serge Knystautas wrote:
> I was wondering if there is a convenient way to restrict method calls on
> objects I put into VelocityContext. I use Velocity templates to do
> dynamic renders high-traffic websites, and I instantiate VelocityEngine
> objects along with various POJOs that Spring assembles. These POJOs are
> sort of like macros and/or scripting support, have been configured with
> setter-injection, and are exposed to templates using a VelocityContext
> object.
>
> My problem is that I intend to reuse these VelocityEngine and POJOs
> across multiple requests, so I do not want to allow template authors to
> call setter methods and effectively reconfigure the POJOs.
>
> Is there an easy way to either have Velocity prevent certain method
> calls on context objects, or otherwise a way to make these POJOs immutable?
>
> --
> Serge Knystautas
> Lokitech >> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
