The remove() method is used in several cases to do some of the cascading needed to maintain consistency properties. Just make sure
to preserve that logic; if you take out the remove() methods, this logic needs to be moved into the corresponding manager methods.
--a.
----- Original Message -----
From: "Lance Lavandowska" <[EMAIL PROTECTED]>
To: <[email protected]>
Sent: Thursday, June 30, 2005 8:24 AM
Subject: Re: velocity context cleanup
On 6/29/05, Allen Gilliland <[EMAIL PROTECTED]> wrote:
*Data.remove() is available to users (try $website.remove() in a template)
This method should probably be removed from the classes. While I
think even POJOs should contain some business logic, I don't feel that
persistence-related methods are appropriate. Because this is only my
personal gut-check, I've never objected.
PageHelper.evaluateString() is available to users (this one actually bit us in the ass already and a user caught themself in a
recursive loop which killed the server)
I'm the one guilty of creating that monstrosity, and I say "get rid of
it". I doubt it is in my real use - but you may break a few pages by
removing it. Perhaps change it to print "THIS MACRO HAS BEEN
REMOVED"? Note: this is a misguided macro, not a Context value.
Some of these may be a simple case of updating the public, protected, private access levels on methods, but some cases may mean
removing objects from the Context and/or removing methods from objects that are part of the Context.
All of the objects placed into the Context are done so to achieve an
objective in the *.vm templates or the Page templates. As I implied
above, let's look at what is being exposed by these objects that may
be 'dangerous' instead.
Lance
