You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by John Menke <jo...@eagleinfosystems.com> on 2002/03/04 23:38:32 UTC
Nesting Extension and persistance strategy
I am planning to use the Nesting Extension in my application and would like
to field comments on how to best implement a database persistance mechanism
in this framework.
The MonkeyStruts example uses one ActionForm bean on the outermost level
that links to other beans recursively in a parent child heirarchy. It looks
like each child bean in the hierarchy is instantiated from methods called by
it's parents class.
I suggest the following for persistance:
ParentBean -> getAllBeansData() (in child bean class) -> getAllBeansData()
in JDBC class -> Parent instantiates new Child bean with the data returned
This way the parent beans control the population of the data in the children
beans as in the example, it just that instead of static data being used it
will come from the database. I think this is correct. Putting the logic to
populate the bean contents in the Action class would take control away from
the parent which seems to be methodology within the Nesting Extension.
When submitting a form I don't want to have to persist the whole tree to the
database each time so I propose adding a property to each bean that will
indicate if the contents are new or changed (dirty). I think I should also
set a property in the outermost bean that indicates if an update, delete or
insert is being performed so that I don't have to look for the dirty bean if
none are dirty. The plan is to then search recursively from parent to child
starting with the outermost bean for the dirty attribute in a bean. If a
bean is dirty I will call a method in a JDBC class associated with the dirty
bean to perform the CRUD action.
To summarize I propose:
1. Populating the form contents with methods contained in JDBC beans called
from the beans themselves. Actually called from a beans parent indirectly.
(Bean parent calls methods in child bean which calls a JDBC bean to get data
for a group of beans that the parent wants to instantiate and then the
parent bean instantiates the beans with the data grabbed from the database)
2. Executing CRUD operations based on beans being marked "dirty" with
methods in JDBC classes from the Action Class assoiated with the form.
Is there a better way of doing this or am I on the right track?
-john
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Nesting Extension and persistance strategy
Posted by Arron Bates <ar...@keyboardmonkey.com>.
John Menke wrote:
>I am planning to use the Nesting Extension...
>
sweet :)
>The MonkeyStruts example uses one ActionForm bean on the outermost level
>that links to other beans recursively in a parent child heirarchy. It looks
>like each child bean in the hierarchy is instantiated from methods called by
>it's parents class.
>
MonkeyStruts example was made only to be just that, an example. To make
it easier to see where things are built, and move on to more important
considerations.
>I suggest the following for persistance...
>
[ ... ]
>Is there a better way of doing this or am I on the right track?
>
No, you're pretty much on the ball really. The only thing that people
pushing "best practices" will say is to make sure that you externalize
the persistence management from the bean model itself. That said, it can
also make life really easy if you drive it directly from within the bean
model itself (Who said that!? :)
In practice, it will really depend on the nature of your data structure.
If it's list style, you'd be mad not to simply drive it from a system
that will query the DB loop through populating objects putting them in a
list. But if it's a complex structure of different nested types (and
lets face it, the nested tags make this possible now more than ever),
you could drive it exactly as you've described having the beans manage
their dirty state and have a one-to-one level mapping from the
persistence mechanism to nested bean (ie: have each nested bean know how
it's to be stored). There are various ways to take this back to the MVC
paradigm keeping the model totally separate, using patterns etc.
Only to say that there's not one recommended system, as it will vary
from requirement to requirement. Some persistence mechanisms, like XML
marshaling, will get you from persistent storage to nested java objects,
back to storage almost for free (although such systems don't have the
brute force performance of a DB query). Where as a table structure page
will be almost the typical top-down list approach. To the ultra simple,
I've made a tiny web app that serializes the entire model to disk. The
data in it was shared to all users, so there wasn't any
concurrency/performance issues.
The nested tags can just be a simpler alternative to the usual Struts
tags, taking the exact same consideration as a typical Struts app.
Horses for courses I'm afraid.
How complex are the types/structure of your hierarchy?...
Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Nesting Extension and persistance strategy
Posted by John Menke <jo...@eagleinfosystems.com>.
Bryan,
i just wish I could have both Simper and Nesting working at once, it would
be the best of both worlds. I'm pretty sure the Nesting Extension needs
concrete classes to work (maybe Aaron will correct me). I have looked into
simper and it looks great, I just don't know how to make the dynamic beans
work with Nesting.
-john
-----Original Message-----
From: Bryan Field-Elliot [mailto:bryan_lists@netmeme.org]
Sent: Monday, March 04, 2002 11:36 PM
To: Struts Users Mailing List
Subject: Re: Nesting Extension and persistance strategy
I don't think what you guys are discussing, is too far off from the
Simper framework I've developed:
http://www.netmeme.org/simper/
It doesn't have anything to do with the current Nesting library, but, it
does many of the things you've discussed in this thread, including
automatic change detection (and writing/committing of changes at the end
of each http request, automatically), as well as support for relations
between tables in a manner similar to the nesting library.
For example, if you have tables named "books" and "authors", and you
have already retrieved a row from the authors table (into the variable
"theAuthor"), you can refer to properties "theAuthor.name",
"theAuthor.address", and you can also refer to relations, such as
"theAuthor.books", which will (on-the-fly) do a query against the books
table for books belonging to the given author, and return a collection.
These can be walked through and displayed using standard <bean:write>,
<logic:iterate>, etc, or they can be updated from within Actions (and
written back to disk at the end of the request).
Bryan
On Mon, 2002-03-04 at 21:16, Arron Bates wrote:
Well, yeah. That'd do the trick too. Probably in a fashion that would be
manageable, clean, and garner the respect of OO gurus, developers and
peers alike. Very apt solution.
You can notify the observer from inside your setters rather than query
the submit button. Mainly because you will have to do some checking to
see if the data did change or if it's just being reset to the same
thing. If you show a form, not change anything and submit it. The data
may as well be totally different, as the bean properties will be set in
each instance anyways. So in your setter you'll have to do comparisons
on the incoming data, may as well just notify the observer while you're
there.
Note: Don't commit or actually make changes as soon as a change is made.
Otherwise you'll have an updates firing for every property, for every
bean. And that would be bad. :) Just note down the changed beans, and
kick off the commit from the observer from within your action. Then you
know that all the bean processing is finished, and you can go ahead and
mess with your bean states.
But to quote Ghostbusters... "yes, have some"
:)
Arron.
John Menke wrote:
> Aaron,
>
> what do you think of implementing the Observable interface with the
> DataBeans? This could help with detecting updates. (Inserts and
Deletes
> are easier because you can determine the action via querying the
submit
> button).
>
> -john
>
>
> --
> 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
Posted by Bryan Field-Elliot <br...@netmeme.org>.
I don't think what you guys are discussing, is too far off from the
Simper framework I've developed:
http://www.netmeme.org/simper/
It doesn't have anything to do with the current Nesting library, but, it
does many of the things you've discussed in this thread, including
automatic change detection (and writing/committing of changes at the end
of each http request, automatically), as well as support for relations
between tables in a manner similar to the nesting library.
For example, if you have tables named "books" and "authors", and you
have already retrieved a row from the authors table (into the variable
"theAuthor"), you can refer to properties "theAuthor.name",
"theAuthor.address", and you can also refer to relations, such as
"theAuthor.books", which will (on-the-fly) do a query against the books
table for books belonging to the given author, and return a collection.
These can be walked through and displayed using standard <bean:write>,
<logic:iterate>, etc, or they can be updated from within Actions (and
written back to disk at the end of the request).
Bryan
On Mon, 2002-03-04 at 21:16, Arron Bates wrote:
Well, yeah. That'd do the trick too. Probably in a fashion that would be
manageable, clean, and garner the respect of OO gurus, developers and
peers alike. Very apt solution.
You can notify the observer from inside your setters rather than query
the submit button. Mainly because you will have to do some checking to
see if the data did change or if it's just being reset to the same
thing. If you show a form, not change anything and submit it. The data
may as well be totally different, as the bean properties will be set in
each instance anyways. So in your setter you'll have to do comparisons
on the incoming data, may as well just notify the observer while you're
there.
Note: Don't commit or actually make changes as soon as a change is made.
Otherwise you'll have an updates firing for every property, for every
bean. And that would be bad. :) Just note down the changed beans, and
kick off the commit from the observer from within your action. Then you
know that all the bean processing is finished, and you can go ahead and
mess with your bean states.
But to quote Ghostbusters... "yes, have some"
:)
Arron.
John Menke wrote:
> Aaron,
>
> what do you think of implementing the Observable interface with the
> DataBeans? This could help with detecting updates. (Inserts and Deletes
> are easier because you can determine the action via querying the submit
> button).
>
> -john
>
>
> --
> 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: deploy weblogic51sp9 sunos 5.8 missing exception detail. :)
Posted by Ivan Siviero <iv...@concept.it>.
Hi again.
I tried to upload the struts-upload application on the server and i get the
same exception again.
If i do not set the xerces.jar in the classpath weblogic tells me it cannot
find the xml parser class org.apache......etc etc..
if i add the xerces.jar to the classpath i get the Parsing error exception
while parsing struts-config.xml.
I do not know what to do.
Can someone give me a clue ?
Ivan.
----- Original Message -----
From: "Ivan Siviero" <iv...@concept.it>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Tuesday, March 05, 2002 9:20 AM
Subject: deploy weblogic51sp9 sunos 5.8 missing exception detail. :)
> Sorry i forgot the exception ! :)
>
> javax.servlet.ServletException: Parsing error processing resource path
> /WEB-INF/struts-config.xml
> at java.lang.Throwable.fillInStackTrace(Native Method)
> at java.lang.Throwable.fillInStackTrace(Compiled Code)
> at java.lang.Throwable.<init>(Compiled Code)
> at java.lang.Exception.<init>(Compiled Code)
> at
javax.servlet.ServletException.<init>(ServletException.java:132)
> at
>
org.apache.struts.action.ActionServlet.initMapping(ActionServlet.java:1279)
> at
> org.apache.struts.action.ActionServlet.init(ActionServlet.java:461)
> at javax.servlet.GenericServlet.init(GenericServlet.java:258)
> at
>
weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java
> :495)
>
>
> ----- Original Message -----
> From: "Ivan Siviero" <iv...@concept.it>
> To: "Struts Users Mailing List" <st...@jakarta.apache.org>
> Sent: Tuesday, March 05, 2002 9:19 AM
> Subject: deploy weblogic51sp9 sunos 5.8
>
>
> > hi everyone.
> >
> > I'm delploying my struts application on weblogic51sp9 and SunOS 5.8.
> > when running weblogic server i get the following exception.
> > It seems to be an xml parser exception.
> > i put the xerces.jar at the beginning of the weblogic classpath but the
> > exception is always raised.
> > The application is not deployed as .war file but i have extracted it and
> > added all the needed classpath to the weblogic classpath.
> > Could someone give me a clue ?
> > Thank you.
> > Ivan.
> >
> >
> >
> > --
> > 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>
deploy weblogic51sp9 sunos 5.8 missing exception detail. :)
Posted by Ivan Siviero <iv...@concept.it>.
Sorry i forgot the exception ! :)
javax.servlet.ServletException: Parsing error processing resource path
/WEB-INF/struts-config.xml
at java.lang.Throwable.fillInStackTrace(Native Method)
at java.lang.Throwable.fillInStackTrace(Compiled Code)
at java.lang.Throwable.<init>(Compiled Code)
at java.lang.Exception.<init>(Compiled Code)
at javax.servlet.ServletException.<init>(ServletException.java:132)
at
org.apache.struts.action.ActionServlet.initMapping(ActionServlet.java:1279)
at
org.apache.struts.action.ActionServlet.init(ActionServlet.java:461)
at javax.servlet.GenericServlet.init(GenericServlet.java:258)
at
weblogic.servlet.internal.ServletStubImpl.createServlet(ServletStubImpl.java
:495)
----- Original Message -----
From: "Ivan Siviero" <iv...@concept.it>
To: "Struts Users Mailing List" <st...@jakarta.apache.org>
Sent: Tuesday, March 05, 2002 9:19 AM
Subject: deploy weblogic51sp9 sunos 5.8
> hi everyone.
>
> I'm delploying my struts application on weblogic51sp9 and SunOS 5.8.
> when running weblogic server i get the following exception.
> It seems to be an xml parser exception.
> i put the xerces.jar at the beginning of the weblogic classpath but the
> exception is always raised.
> The application is not deployed as .war file but i have extracted it and
> added all the needed classpath to the weblogic classpath.
> Could someone give me a clue ?
> Thank you.
> Ivan.
>
>
>
> --
> 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>
deploy weblogic51sp9 sunos 5.8
Posted by Ivan Siviero <iv...@concept.it>.
hi everyone.
I'm delploying my struts application on weblogic51sp9 and SunOS 5.8.
when running weblogic server i get the following exception.
It seems to be an xml parser exception.
i put the xerces.jar at the beginning of the weblogic classpath but the
exception is always raised.
The application is not deployed as .war file but i have extracted it and
added all the needed classpath to the weblogic classpath.
Could someone give me a clue ?
Thank you.
Ivan.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Nesting Extension and persistance strategy
Posted by Arron Bates <ar...@pacific.net.au>.
Mutually exclusive domains of operation.
I don't see any reason as to why the nested tags wouldn't work with simper.
The tags are just that. tags. They will interpret any bean they get
their hands on when the JSP gets evaluated. So simper and NeXt could
possibly be perfect buddies. The tags only add to the additional struts
tags so that they relate to each other, rather then them all be an
island that have to be managed separately. Struts already had nested
beans, it was just that marking it up was kind of crappy, and actually
brought limitation to a very flexible ability. Enough of that rant...
So if simper works against the current Struts tags, "stacks-on" for the
nested version. :)
Arron.
John Menke wrote:
> Aaron,
>
> I think this is the way to go. Notify the observer from within the setter
> making sure the data has changed. I think I can make an Observer class
> that
> will store a collection of objects that have changed. Then I can query
> this
> collection in the Action and perform the updates. Maybe I should look
> deeper into Simper to see how the "dirtybeans" work. It would be great if
> Simper and Nested Tags worked together. You could have the best of both
> worlds. Dynamic persistance and great flexibility in the view.
>
> -john
>
>
> -----Original Message-----
> From: Arron Bates [ mailto:arronb@pacific.net.au ]
> Sent: Monday, March 04, 2002 11:17 PM
> To: Struts Users Mailing List
> Subject: Re: Nesting Extension and persistance strategy
>
>
> Well, yeah. That'd do the trick too. Probably in a fashion that would be
> manageable, clean, and garner the respect of OO gurus, developers and
> peers alike. Very apt solution.
>
> You can notify the observer from inside your setters rather than query
> the submit button. Mainly because you will have to do some checking to
> see if the data did change or if it's just being reset to the same
> thing. If you show a form, not change anything and submit it. The data
> may as well be totally different, as the bean properties will be set in
> each instance anyways. So in your setter you'll have to do comparisons
> on the incoming data, may as well just notify the observer while you're
> there.
>
> Note: Don't commit or actually make changes as soon as a change is made.
> Otherwise you'll have an updates firing for every property, for every
> bean. And that would be bad. :) Just note down the changed beans, and
> kick off the commit from the observer from within your action. Then you
> know that all the bean processing is finished, and you can go ahead and
> mess with your bean states.
>
> But to quote Ghostbusters... "yes, have some"
> :)
>
> Arron.
>
> John Menke wrote:
>
>> Aaron,
>>
>> what do you think of implementing the Observable interface with the
>> DataBeans? This could help with detecting updates. (Inserts and Deletes
>> are easier because you can determine the action via querying the submit
>> button).
>>
>> -john
>>
>>
>> --
>> 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
Posted by John Menke <jo...@eagleinfosystems.com>.
>>I don't see any reason as to why the nested tags wouldn't work with
simper.
Then I will try to get them working together (simper -- NeXt), Having a
problem downloading
the simper-src.jar from SourceForge download always fininshes but winzip
complains
that archive is missing bytes...
At the least, trying to get Simper to work with NeXt should shed some light
on how to
solve the dirty bean problem but at best may preclude having to design a
solution at all.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Nesting Extension and persistance strategy
Posted by Arron Bates <ar...@keyboardmonkey.com>.
I don't see any reason as to why the nested tags wouldn't work with simper.
The tags are just that. tags. They will interpret any bean they get
their hands on when the JSP gets evaluated. So simper and NeXt could
possibly be perfect buddies. The tags only add to the additional struts
tags so that they relate to each other, rather then them all be an
island that have to be managed separately. Struts already had nested
beans, it was just that marking it up was kind of crappy, and actually
brought limitation to a very flexible ability. Enough of that rant...
So if simper works against the current Struts tags, "stacks-on" for the
nested version. :)
Arron.
John Menke wrote:
>Aaron,
>
>I think this is the way to go. Notify the observer from within the setter
>making sure the data has changed. I think I can make an Observer class that
>will store a collection of objects that have changed. Then I can query this
>collection in the Action and perform the updates. Maybe I should look
>deeper into Simper to see how the "dirtybeans" work. It would be great if
>Simper and Nested Tags worked together. You could have the best of both
>worlds. Dynamic persistance and great flexibility in the view.
>
>-john
>
>
>-----Original Message-----
>From: Arron Bates [mailto:arronb@pacific.net.au]
>Sent: Monday, March 04, 2002 11:17 PM
>To: Struts Users Mailing List
>Subject: Re: Nesting Extension and persistance strategy
>
>
>Well, yeah. That'd do the trick too. Probably in a fashion that would be
>manageable, clean, and garner the respect of OO gurus, developers and
>peers alike. Very apt solution.
>
>You can notify the observer from inside your setters rather than query
>the submit button. Mainly because you will have to do some checking to
>see if the data did change or if it's just being reset to the same
>thing. If you show a form, not change anything and submit it. The data
>may as well be totally different, as the bean properties will be set in
>each instance anyways. So in your setter you'll have to do comparisons
>on the incoming data, may as well just notify the observer while you're
>there.
>
>Note: Don't commit or actually make changes as soon as a change is made.
>Otherwise you'll have an updates firing for every property, for every
>bean. And that would be bad. :) Just note down the changed beans, and
>kick off the commit from the observer from within your action. Then you
>know that all the bean processing is finished, and you can go ahead and
>mess with your bean states.
>
>But to quote Ghostbusters... "yes, have some"
>:)
>
>Arron.
>
>John Menke wrote:
>
>>Aaron,
>>
>>what do you think of implementing the Observable interface with the
>>DataBeans? This could help with detecting updates. (Inserts and Deletes
>>are easier because you can determine the action via querying the submit
>>button).
>>
>>-john
>>
>>
>>--
>>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
Posted by John Menke <jo...@eagleinfosystems.com>.
Aaron,
I think this is the way to go. Notify the observer from within the setter
making sure the data has changed. I think I can make an Observer class that
will store a collection of objects that have changed. Then I can query this
collection in the Action and perform the updates. Maybe I should look
deeper into Simper to see how the "dirtybeans" work. It would be great if
Simper and Nested Tags worked together. You could have the best of both
worlds. Dynamic persistance and great flexibility in the view.
-john
-----Original Message-----
From: Arron Bates [mailto:arronb@pacific.net.au]
Sent: Monday, March 04, 2002 11:17 PM
To: Struts Users Mailing List
Subject: Re: Nesting Extension and persistance strategy
Well, yeah. That'd do the trick too. Probably in a fashion that would be
manageable, clean, and garner the respect of OO gurus, developers and
peers alike. Very apt solution.
You can notify the observer from inside your setters rather than query
the submit button. Mainly because you will have to do some checking to
see if the data did change or if it's just being reset to the same
thing. If you show a form, not change anything and submit it. The data
may as well be totally different, as the bean properties will be set in
each instance anyways. So in your setter you'll have to do comparisons
on the incoming data, may as well just notify the observer while you're
there.
Note: Don't commit or actually make changes as soon as a change is made.
Otherwise you'll have an updates firing for every property, for every
bean. And that would be bad. :) Just note down the changed beans, and
kick off the commit from the observer from within your action. Then you
know that all the bean processing is finished, and you can go ahead and
mess with your bean states.
But to quote Ghostbusters... "yes, have some"
:)
Arron.
John Menke wrote:
> Aaron,
>
> what do you think of implementing the Observable interface with the
> DataBeans? This could help with detecting updates. (Inserts and Deletes
> are easier because you can determine the action via querying the submit
> button).
>
> -john
>
>
> --
> 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
Posted by Arron Bates <ar...@pacific.net.au>.
Well, yeah. That'd do the trick too. Probably in a fashion that would be
manageable, clean, and garner the respect of OO gurus, developers and
peers alike. Very apt solution.
You can notify the observer from inside your setters rather than query
the submit button. Mainly because you will have to do some checking to
see if the data did change or if it's just being reset to the same
thing. If you show a form, not change anything and submit it. The data
may as well be totally different, as the bean properties will be set in
each instance anyways. So in your setter you'll have to do comparisons
on the incoming data, may as well just notify the observer while you're
there.
Note: Don't commit or actually make changes as soon as a change is made.
Otherwise you'll have an updates firing for every property, for every
bean. And that would be bad. :) Just note down the changed beans, and
kick off the commit from the observer from within your action. Then you
know that all the bean processing is finished, and you can go ahead and
mess with your bean states.
But to quote Ghostbusters... "yes, have some"
:)
Arron.
John Menke wrote:
> Aaron,
>
> what do you think of implementing the Observable interface with the
> DataBeans? This could help with detecting updates. (Inserts and Deletes
> are easier because you can determine the action via querying the submit
> button).
>
> -john
>
>
> --
> 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
Posted by Arron Bates <ar...@keyboardmonkey.com>.
Well, yeah. That'd do the trick too. Probably in a fashion that would be
manageable, clean, and garner the respect of OO gurus, developers and
peers alike. Very apt solution.
You can notify the observer from inside your setters rather than query
the submit button. Mainly because you will have to do some checking to
see if the data did change or if it's just being reset to the same
thing. If you show a form, not change anything and submit it. The data
may as well be totally different, as the bean properties will be set in
each instance anyways. So in your setter you'll have to do comparisons
on the incoming data, may as well just notify the observer while you're
there.
Note: Don't commit or actually make changes as soon as a change is made.
Otherwise you'll have an updates firing for every property, for every
bean. And that would be bad. :) Just note down the changed beans, and
kick off the commit from the observer from within your action. Then you
know that all the bean processing is finished, and you can go ahead and
mess with your bean states.
But to quote Ghostbusters... "yes, have some"
:)
Arron.
John Menke wrote:
>Aaron,
>
>what do you think of implementing the Observable interface with the
>DataBeans? This could help with detecting updates. (Inserts and Deletes
>are easier because you can determine the action via querying the submit
>button).
>
>-john
>
>
>--
>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
Posted by John Menke <jo...@eagleinfosystems.com>.
Aaron,
what do you think of implementing the Observable interface with the
DataBeans? This could help with detecting updates. (Inserts and Deletes
are easier because you can determine the action via querying the submit
button).
-john
--
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>
Re: Nesting Extension and persistance strategy--castor any one?
Posted by rajesh kalluri <ra...@manduca.com>.
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
Posted by Arron Bates <ar...@pacific.net.au>.
>
>
> 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>
Re: Nesting Extension and persistance strategy
Posted by Arron Bates <ar...@keyboardmonkey.com>.
>
>
>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>
RE: Nesting Extension and persistance strategy
Posted by John Menke <jo...@eagleinfosystems.com>.
>>you could drive it exactly as you've described having the beans manage
>>their dirty state and have a one-to-one level mapping from the
>>persistence mechanism to nested bean (ie: have each nested bean know how
>>it's to be stored). There are various ways to take this back to the MVC
>>paradigm keeping the model totally separate, using patterns etc.
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.
>>How complex are the types/structure of your hierarchy?...
Pretty simple. Actually it almost maps exactly to your example
Organization
Team
Investor
Portfolio
Stock
-john
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Nesting Extension and persistance strategy
Posted by Arron Bates <ar...@pacific.net.au>.
John Menke wrote:
> I am planning to use the Nesting Extension...
>
sweet :)
> The MonkeyStruts example uses one ActionForm bean on the outermost level
> that links to other beans recursively in a parent child heirarchy. It
> looks
> like each child bean in the hierarchy is instantiated from methods
> called by
> it's parents class.
>
MonkeyStruts example was made only to be just that, an example. To make
it easier to see where things are built, and move on to more important
considerations.
> I suggest the following for persistance...
>
[ ... ]
> Is there a better way of doing this or am I on the right track?
>
No, you're pretty much on the ball really. The only thing that people
pushing "best practices" will say is to make sure that you externalize
the persistence management from the bean model itself. That said, it can
also make life really easy if you drive it directly from within the bean
model itself (Who said that!? :)
In practice, it will really depend on the nature of your data structure.
If it's list style, you'd be mad not to simply drive it from a system
that will query the DB loop through populating objects putting them in a
list. But if it's a complex structure of different nested types (and
lets face it, the nested tags make this possible now more than ever),
you could drive it exactly as you've described having the beans manage
their dirty state and have a one-to-one level mapping from the
persistence mechanism to nested bean (ie: have each nested bean know how
it's to be stored). There are various ways to take this back to the MVC
paradigm keeping the model totally separate, using patterns etc.
Only to say that there's not one recommended system, as it will vary
from requirement to requirement. Some persistence mechanisms, like XML
marshaling, will get you from persistent storage to nested java objects,
back to storage almost for free (although such systems don't have the
brute force performance of a DB query). Where as a table structure page
will be almost the typical top-down list approach. To the ultra simple,
I've made a tiny web app that serializes the entire model to disk. The
data in it was shared to all users, so there wasn't any
concurrency/performance issues.
The nested tags can just be a simpler alternative to the usual Struts
tags, taking the exact same consideration as a typical Struts app.
Horses for courses I'm afraid.
How complex are the types/structure of your hierarchy?...
Arron.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>