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]>
