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:[EMAIL PROTECTED]] 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: > <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]>
