You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by rajesh kalluri <ra...@manduca.com> on 2002/03/05 17:32:29 UTC

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: kallurirajesh@aol.com
Phone: 786-552-0521
Fax: 786-552-0501

----- Original Message -----
From: "Arron Bates" <ar...@pacific.net.au>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Nesting Extension and persistance strategy--castor any one?

Posted by Arron Bates <ar...@pacific.net.au>.
Castor works a treat. If castor had finer grained validation mechanism, 
we could use it to validate automatically also and relieve another 
burden. I've used Castor before, but not as the model directly. But it's 
very possible. A very good system.

Castor, of course, does everything via XML Schema definition. But it's 
very complete.

Arron.


John Menke wrote:

>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:rajesh@manduca.com]
>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: kallurirajesh@aol.com
>Phone: 786-552-0521
>Fax: 786-552-0501
>
>----- Original Message -----
>From: "Arron Bates" <ar...@pacific.net.au>
>To: "Struts Users Mailing List" <st...@jakarta.apache.org>
>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:
>>
><ma...@jakarta.apache.org>
>
>>For additional commands, e-mail:
>>
><ma...@jakarta.apache.org>
>
>>
>
>
>--
>To unsubscribe, e-mail:
><ma...@jakarta.apache.org>
>For additional commands, e-mail:
><ma...@jakarta.apache.org>
>
>
>--
>To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
>
>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: Nesting Extension and persistance strategy--castor any one?

Posted by John Menke <jo...@eagleinfosystems.com>.
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:rajesh@manduca.com]
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: kallurirajesh@aol.com
Phone: 786-552-0521
Fax: 786-552-0501

----- Original Message -----
From: "Arron Bates" <ar...@pacific.net.au>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
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:
<ma...@jakarta.apache.org>
> For additional commands, e-mail:
<ma...@jakarta.apache.org>
>
>


--
To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail:
<ma...@jakarta.apache.org>


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>