This response in now way constitutes an honest attempt at a resolution for this issue (as I have not yet had a chance to even look at the DynaForm class). With the disclaimer out of the way, let me tell you what I do on my current assignment and perhaps some of this can be adapted:
Because my application has so many screens and is so database heavy, all of my validation and business logic resides in the EJB tier (the app is so variable, I do not even know if a field is required unless I check the DB to tell me -- obviously I cache this info). I do not use any form-beans but load all request parameters into a Properties object (ignoring anything that evaluates to a ""). When my EJB is ready to validate the input, I load the properties into a value object (my VOs have no get/set methods, but all variables as public, hence they are VERY light). The VO has the attributes in a number of Object types (since the VOs normally model the DB data, they have the common date/timestamp/string/int/double/etc. types). I have another class of static methods that does conversions from Strings to Objects/primitives (int, double, boolean, etc.). The loadValueObject(Properties) method traverses the matches between the parameter names and VO attribute names and then invokes the String conversion method to the appropriate type. This is a very easy approach and works VERY fast. I have not had to do any conversions beyond this again, and it's easy for new developers to jump on board and use. I would be willing to work with someone more familiar with the DynaForm issue to adapt my approach to the Struts approach if you'd like. --- Nathan Bubna <[EMAIL PROTECTED]> wrote: > Craig said: > [snip] > > > > A common approach is to provide a separate property on > the form bean > to > > > > grab the converted value. The property setter for the > String property > > > > tries to do the conversion if it can, and caches the > result if > successful. > > > > Your action can then grab the preconverted values. > > > > > > yes, but this doesn't work for DynaActionForms, does it? > i am little > > > interested in a solution that requires my creating an > ActionForm > subclass > > > for every html form i've got. for we have a great many of > them and they > are > > > not simple. > > > > > > > It can be made to work, but is not code-free for the > developer -- that is, > > until someone creates a little utility that can look at the > <form-bean> > > definition (or something like it) and generate the necessary > Java class. > > huh? i don't follow. why would we need to generate a new > Java class? i do > *not* want to get into that. i think this could be done at > least for > standard java types (Integer, Double and friends) by just > altering > DynaActionForm and DynaValidatorForm. and if they're provided > the hooks for > converters for other types, i think they could handle those as > well. > > > Whatever the outcome of that is, it won't be part of 1.1 > officially, but > > an add-on that does this sort of thing would be quite > useful. > > yeah, i wouldn't want to put something that's generating Java > classes into > 1.1 either. but that's not my suggestion. perhaps i'll try > and dig up some > time to try it out myself and submit a patch. it's shouldn't > be that > complicated at all. as to whether it would belong in 1.1, > i'll leave that > to others. it would after all change the semantic of the > "type" attribute > for <form-property> as well as changing > DynaActionForm.get(name) to return > java.lang.String and adding a > DynaActionForm.getConvertedValue(name) method. > > > > to be honest, i'm really lazy when it comes to repetitive > tasks. i even > tir > > > e of doing type="java.lang.String" for every field in my > DynaActionForms. > > > (if that is the recommended procedure, why is it not an > automagic > default?) > > > i would prefer to define the type i actually want and have > some standard > > > means to extract that converted value from the > DynaActionForm. > > > > > > what i desire is to have DynaActionForm gain a method > along the lines > of: > > > > > > public Object getConverted(String name) > > > > > > and change get(String) into: > > > > > > public String get(String name) > > > > > > these would then behave in such a manner that configuring > my xml like: > > > > > > <form-bean name="fooForm" > > > > type="org.apache.struts.validator.DynaActionForm"> > > > <form-property name="foo" type="com.org.Whatever"/> > > > </form-bean> > > > > > > would result in: > > > > > > get(String) - always returns the unconverted string > retrieved from the > > > request params (as is the result of the recommended > practice of always > > > defining the type as java.lang.String and maintains the > desired user > > > experience) > > > > > > getConverted(String) - will return an instance of > com.org.Whatever if > the > > > conversion was successful, or null otherwise > > > > > > this could prevent doing two separate conversions when > validation is > added > > > to the picture, and would make developers happy. > [snip] > > Nathan Bubna > [EMAIL PROTECTED] > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > __________________________________________________ Do You Yahoo!? HotJobs - Search Thousands of New Jobs http://www.hotjobs.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
