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:[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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
