I am now using nested tags everywhere and not programming my action forms with getter and setter methods for anything except one or two properties, and the nested beans of course.
Is there any reason to regard this as bad practice? I also write my value beans with two properties for every real property, one is typed, e.g. Date, and the other is the string representation of the type. So I also have two getters and two setters. Also again I have the validation code in the value bean which populates the typed property from the string representation property. The action form loops through the beans calling the validate methods. It means I have all my properties in one bean rather than also in the form bean - easier to change when the entity changes. Adam Craig R. McClanahan wrote: > > On Wed, 17 Jul 2002, Rick Reumann wrote: > > >>Date: Wed, 17 Jul 2002 20:57:26 -0400 >>From: Rick Reumann <[EMAIL PROTECTED]> >>To: Craig R. McClanahan <[EMAIL PROTECTED]> >>Cc: Roman Fail <[EMAIL PROTECTED]>, >> Struts Users Mailing List <[EMAIL PROTECTED]>, >> [EMAIL PROTECTED] >>Subject: Re[4]: getting nested tags to work with DynaActionForm??? >> >>On Wednesday, July 17, 2002, 7:39:23 PM, Craig wrote: >> >> >>>> Agreed, that does walk into the realm of Big Brother code. I guess >>>>it's just going to be a rough spot for DynaNewbies. >>> >>CRM> Not any rougher than it is for people trying to understand standard >>CRM> ActionForms :-) >> >> Correct me if I'm wrong here Craig, but where I noticed it was >> quite a bit more difficult is when you decide not to use Session >> scope for FormBeans that have ArrayLists with beans inside that >> also have ArrayLists (etc. with nesting ). I say this because if >> I remember correctly isn't one of the main differences between >> the DynaActionForm and the standard ActionForm is that the >> DynaActionForm ALWAYS calls the reset method (regardless of >> scope) whereas the ActionForm only calls it when in it's in >> request scope (or explicitly called?). This is where I think I >> was running into trouble, since even though my DynaActionForm had >> session scope it was always calling reset whereas my standard >> ActionForm in session scope was not calling it. >> > > > That's not quite accurate. > > Struts (all versions) always calls reset() when you flow through the > controller servlet. However, if you went directly to a JSP page, and the > <html:form> tag creates the form bean (quite common if the form bean is > defined to be in request scope), Struts 1.0 did not call reset() but > Struts 1.1 does. In the 1.1 case, it makes no difference at all whether > it is an ActionForm or a DynaActionForm. > > >> So in my case if I wanted request scope for the ActionForm I >> still would have had to override the reset method to provide a >> way to initialize the ArrayLists (and I take it the beans inside >> with ArrayLists as well). > > > That is true for both kinds of beans. In either case, you can also choose > to make the constructor do this sort of initialization (requires a > DynaActionForm subclass in the dynamic case, but it's still possible). > > >>In my case however it's not too big of >> a deal that this UserFormBean hang around for a while with >> Session scope so it seems much easier to use it with an >> ActionForm than with the DynaActionForm (since with the later >> case I'm forced to override the reset method and populate nested >> beans). >> > > > That should be the case for either kind of form bean. Can you show me an > example of where it's different? > > >> This is probably a dumb question and I suppose I could try it >> before posting, but what would happen if I just wanted to use the >> DynaActionForm in session scope and then just overrode the reset >> method to do nothing? > > > You'd mess up the initializations based on the "initial" attribute :-). > > >>Wouldn't it still keep the values in the >> DynaActionForm since it had session scope and wouldn't try to >> set up unitialized ArrayLists, etc? (of course this would only >> help if the bean was in Session scope..but just curious if it >> would even work). >> >> Thanks again for all of your comments so far >> > > > It might do what you want, but for the wrong reasons. > > I think it's time to get into specific use cases to further this > discussion. > > >>-- >> >>Rick >>mailto:[EMAIL PROTECTED] >> >> > > > Craig > > > > -- > 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]>
