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