The PageField's internal storage is a simple String. It could easily be changed to anything else, though. If the field maps to a model bean, it handles nested and indexed properties the same way Struts does. In fact it uses BeanUtils and PropertyUtils. If the field does not map to a bean, it can only be a String, but this is just a design flaw. After sending that post, I decided to write an implementation that works with Struts and post it for anyone who is interested.
> -----Original Message----- > From: Dan Cancro [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 09, 2002 12:33 PM > To: 'Struts Users Mailing List' > Subject: RE: DynaActionForm Advantages (A different approach) > > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
