+1!!!
I'm guilty of moving methods like save(), remove(), etc. into the
POJOs. I think everything you've outlined below is basically a good
idea, but I'd like to hold off on it until we merge 2.0 back in.
- Dave
On Jun 30, 2005, at 10:50 AM, Allen Gilliland wrote:
Okay, so it sounds like a few other people have given this a little
thought and think that it may be beneficial to make some changes to
the way the Pojos and PersistentObjects work. I think it would help
to add a little more detail to the discussion so we know what we are
talking about. Here's my stab at what changes I would think about
making ...
- move PersistentObject.save() into Manager classes only
- move PersistentObject.remove() into Manager classes only
I think those 2 changes would go a long ways toward making it less
dangerous to make Pojos directly available to users via the velocity
context. I am in partial agreement that we may not need the
PersistentObject class at all. Right now I would also consider doing
...
- remove PersistentObject.get/setId() (these are not necessarily part
of all objects)
- remove PersistentObject.setData() (this can easily be done elsewhere)
- remove PersistentObject.canSave() (i don't fully understand how this
is used, but i believe this logic can be in the Manager classes
save/remove methods)
If we also want to do those last few items then the PersistentObject
class would basically be useless. I think the first 2 are pretty
important, but the last 3 are optional. Personally I would probably
go ahead and ditch the PersistentObject class just because I don't
think we really need it.
what do others think?
Remember, we are just talking about this right now so please speak up
and voice your opinion. We aren't going to make any changes right
away, especially with the fact that Dave has a lot of data model work
going on for the 2.0 release and we don't want to mess with what he
has done so far. Once we get a bit more consenus then I will
formalize a Proposal that can be reviewed again.
-- Allen
On Thu, 2005-06-30 at 10:12, Rudman Max wrote:
I just wanted to chime in that I really dislike persistence methods
being in POJOs also and would be willing to pitch in with moving
those out to the appropriate manager classes. In fact, I would even
like to see PersistenceObject go as having to extend data objects
from it pretty much negates one of the key benefits of Hibernate --
its non-intrusiveness into the object model.
Max
On Jun 30, 2005, at 11:53 AM, Anil Gangolli wrote:
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
