How does your PageField list handle iterative and nested properties? Can a PageField's value be a String array?
> -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 10:22 AM > To: [EMAIL PROTECTED] > Subject: RE: DynaActionForm Advantages (A different approach) > > > Something that has always bothered me in Struts is the "disconnect" > between Form Beans and Model Beans. How many times do you have a Form > Bean and a model bean that contain the same data? The > disconnect makes > some sense because you want everything that could come in from a JSP > page to be String-based, while you want the properties of your model > beans to be properly typed. Plus there are often things on the Form > Bean that will not be in the model bean or will be represented > differently. But I've found myself constantly trying to find an easy > way to map the data from my form beans back to the model > beans in Struts > without manually copying the data. It appears DynaBeans > don't fix this. > > Our company has developed a framework loosely based on > Struts, that has > a single component for storing page data and mapping it back to model > beans. Each JSP page has a bean that holds its data. The data is > contained in a list of PageField objects. The PageField has > getFieldValue() and setFieldValue() methods that return and > take Strings > respectively. The PageField also has a mapping that will map > the field > back to a model bean, if desired. The mapping is specified in the JSP > tag. Page data that is contained in a model bean is automatically > retrieved from and populated to the model bean by reflection. > Page data > that does not cleanly map back to the bean is kept in PageField's > internal storage. > > This works great for us because we do not have to write form beans for > every page. Whatever beans we need to use are automatically populated > by the framework. > > Would something like this be useful to the Struts community? > Do you see > issues with the approach? > > Thanks, > Greg > > > -----Original Message----- > > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, July 09, 2002 11:47 AM > > To: Struts Users Mailing List > > Subject: Re: DynaActionForm Advantages > > > > > > > > > > On Tue, 9 Jul 2002, Glen Mazza wrote: > > > > > Date: Tue, 9 Jul 2002 09:58:29 -0500 (CDT) > > > From: Glen Mazza <[EMAIL PROTECTED]> > > > Reply-To: Struts Users Mailing List > <[EMAIL PROTECTED]> > > > To: [EMAIL PROTECTED] > > > Subject: Re: DynaActionForm Advantages > > > > > > > Fecha: Mon, 08 Jul 2002 23:37:03 -0400 > > > > A: [EMAIL PROTECTED] > > > > De: James Turner <[EMAIL PROTECTED]> > > > > Asunto: RE: DynaActionForm Advantages > > > > > > > > My two cents on the topic. > > > > > > > > As mentioned, once you move to a good Java IDE like > > > > JBuilder, writing > > > > getters and setters is no longer nearly the pain it > > > > used to be. > > > > > > > > > > Correct--the ActionForm follows the standard JavaBeans > > > approach--reduced learning curve for newcomers, and > > > already generated by most IDE's. > > > > > > > > > > What bothers me about the DynaBean approach is that > > > > it's *yet another* > > > > file, and *yet another* level of indirection that > > > > obscure what's really > > > > going on. I can look at an ActionForm, see all the > > > > properties, look at the > > > > validation, all in one step. Making it a DynaBean > > > > form means having to > > > > maintain another file with the XML, always having to > > > > remember where it is, etc. > > > > > > > > > > Mostly agree. It's not "yet another" file, because > > > DAF's were (I believe) originally designed to reduce > > > the number of ActionForms you'd have to implement. > > > I.e., if you don't have any special validation to do, > > > don't bother subclassing an ActionForm--just put the > > > variables in the struts-config and you're done. Very > > > nice design. > > > > > > The problem was that the DAF class was not made final. > > > Allowing it to be subclassed is creating the mess you > > > describe--the variables in the XML file and actions on > > > them in the DAF subclass. (Another was writing about > > > putting member variable initializations in the > > > validate() function--the DAF subclass may also start > > > encouraging other messier programming habits.) > > > > > > As for those who don't like getter/setters and want to > > > use the common-beanutils "get" functions described by > > > Craig: Might it have been better, in addition to > > > making the DAF class final, > > > > Making DAF final would have prevented the use case where you want to > > subclass it for custom reset() or validate() methods. This > would have > > forced the use of two classes instead of one -- IMHO that > > would have been > > more confusing, not less. > > > > > to just have ActionForms > > > implement "get"'s interface? Just newbie thinking... > > > > And the "set" methods also, I presume? That's an interesting > > idea -- then > > users of the form beans could always use get()/set() and not > > care whether > > it was actually a DynaActionForm or not ... > > > > > > > > Glen > > > > > > > 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]> > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
