Rajesh,
That sounds interesting. I started looking at Castor also, but now I'm
looking more into Simper. Let me know how it goes maybe we can share notes.
-john
-Original Message-
From: rajesh kalluri [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, March 05, 2002 11:32 AM
To: Struts Users Mailing List
Subject: Re: Nesting Extension and persistance strategy--castor any one?
Hi All,
I am not the expert in the field of designing OO persistence mechanisms.
I am a fan of nested beans and also i have been playing with castor lately.
So am thinking if we can map our monkey object schema to a db schema (I can
hear a lot of thats easy). Then it should be a snap to marshall/unmarshall
monkey beans (nested in general) into XML files/ data base tables.
I would start playing with it as soon as i have time.
Regards
Rajesh Kalluri.
Manduca Management LLC,
Suite 230, 5757 Blue Lagoon Dr.
Miami, FL 33126.
AIM: [EMAIL PROTECTED]
Phone: 786-552-0521
Fax: 786-552-0501
- Original Message -
From: Arron Bates [EMAIL PROTECTED]
To: Struts Users Mailing List [EMAIL PROTECTED]
Sent: Monday, March 04, 2002 11:16 PM
Subject: Re: Nesting Extension and persistance strategy
I like beans managing dirty state becuause I could possibly have one
method
that can handle several different structures if it's designed right.
Maybe this:
Have all DataBeans implement an interface lets day DirtyInterface that
defines
2 methods:
public String getDirtyAttribute() and
public void callJDBC(String dirtyAttribute)
the dirtyAttribute class member could be one of several values:
insert
update
delete
(select)
callJDBCbean(String dirtyAttribute) would call a JDBCbean
corresponding to
the databean,
not sure how to define this, maybe in a way similar to the mapping of
Actions?
So then in the Action associated with the ActionForm we could pass the
ActionForm into a Method that will call getDirtyAttribute and
callJDBCbean
for each bean that is nested within the ActionForm.
Having trouble thinking of way to iterate through the beans, but I think
it's possible.
I think that to get it more in line with the stupid-model-paradigm (SMP?
:) your beans could manage their dirty state, but the actual persistence
management be handled by a separate object, that takes the bean types in
overloaded methods.
eg:
persistDirtyBean(Organisation org) {...}
persistDirtyBean(Team team) {...}
persistDirtyBean(Investor investor) {...}
persistDirtyBean(Portfolio portfolio) {...}
persistDirtyBean(Stock stock) {...}
Then you could just throw whatever bean at it you needed. The class
itself could even iterate the tree itself, in that the Organisation
version of the PersistDirtyBean would get Team objects, and then from
this method could call the Team persist method for whatever team. Or you
can, in just as correct a manner, use it ad-hoc just throwing whatever
object. Means that the persist methods aren't living with their related
Object, so some OO guru may say it's not defending the faith.
There's just so many ways you can attack this. But I think that you're
in the right frame of mind to take it on at least. :)
How complex are the types/structure of your hierarchy?...
Pretty simple. Actually it almost maps exactly to your example
Organization
Team
Investor
Portfolio
Stock
Simple until you have to persist the thing. :)
My definition of simple is when making a table you have a bean with a
collection of one type of object, that can be retrieved and updated with
one query.
Oh, I miss those days when people thought that just seeing data was
special...
...and that it was on the Information Super-Highway... there's a term
that brings on flash-backs.
Arron.
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail:
mailto:[EMAIL PROTECTED]
For additional commands, e-mail:
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: mailto:[EMAIL PROTECTED]
For additional commands, e-mail: mailto:[EMAIL PROTECTED]
