> I appreciate centralizing properties, but I think some > of the properties you mentioned (i.e. style, > title/titleKey, etc.) are not really in the buffer > space, but solidly fixed in the html/jsp space. I > think it is probably a violation of the separation of > concerns to define such UI specific elements outside > of the space they come from. I do like the idea of > combining the validation definition with target > datatype/conversion mechanism to simplify the work of > defining a UI field. Perhaps the Struts schema could > wrap (and expand upon) the elements in the validation > dtd allowing for a single point of entry for field > definitions?
Once you combine struts-config.xml with validation.xml you lose the ability to leverage commons-validator's ability to parse validation.xml and configure itself. Struts would have to setup commons-validator itself which isn't rocket science but it's probably not trivial either. David > > --- Ted Husted <[EMAIL PROTECTED]> wrote: > > Fixing ConvertUtils would seem like a better > > solution to me than making > > this many workarounds to support a single data type. > > > > If we make these kind of patches to Struts, we've > > only "helped" Struts. > > If we fix ConvertUtils, we can help any other > > application or framework > > that uses ConvertUtils. > > > > I believe the consensus has been that the ActionForm > > should represent > > Strings as they are entered into the HTML form. Once > > the Strings pass > > validation, then data conversion should occur as the > > data moves toward > > the business and system tiers. > > > > I would agree that the ActionForm oversimplifies the > > problem. There is > > definitely a need for a object that incorporates > > many more attributes > > into a single configuration, target datatype being > > one of these. But, > > IMHO, offering up a patch for just the Date datatype > > would be a step in > > the wrong direction. > > > > We've come to say that the ActionForm is the missing > > buffer for the HTML > > controls. I would suggest that we should take that > > to heart and make it > > an actual buffer object for data-entry controls. > > We've already started > > to add a second layer of description to the > > ActionForm in the guise of > > the Validator forms. We've also started to define > > the ActionForm itself > > in XML under the auspice of DynaValidatorForm. > > Perhaps we should put > > both of these things together and define a true > > field and form buffer > > object that can be define in XML. > > > > Aside from target datatype, the Field/Form > > descriptor could also have > > places to define the label, displaysize, maxlength, > > control, readonly, > > disabled, tabindex, required, validator, default, > > alt, altKey, style, > > styleClass, styleId, title, titleKey, and Java on* > > events. > > > > We already enter all of these things into the > > application someplace, and > > it would be helpful if they could all be gathered > > together where they > > could be reused. > > > > The object would be an excellent place to put more > > advanced data > > conversion routines, such as those required for > > dates. It could also be > > used by other applications and frameworks outside of > > Struts. > > > > -Ted. > > > > Jon Wilmoth wrote: > > > As I've found with my involvement in contributing > > to > > > the Bugzilla project, radification/confirmation of > > > design/implementation details is critical to > > > acceptance of a submitted patch. Below are the > > > changes I propose to make this happen. The String > > --> > > > Date direction is significanly more involved than > > > rendering the date as a String. I investigated > > > performing the conversion in ConvertUtils for > > both, > > > but without overloading the Converter.convert > > > interface to accept a map of conversion parameters > > > made available to the registered Converter > > > implementations this is not possible. Further > > more, > > > the BeanUtils.populate method signature would also > > > need to change to accomodate a collection of > > property > > > specific conversion parameter name/value pairs to > > use > > > this new convert method. Thus what's outlined > > below > > > involves changes in the Struts code base only! > > > > > > String --> Date > > > 1) Add "dateformat" attribute to all html input > > tags. > > > This would specify the java.text.SimpleDateFormat > > > pattern of the string being submitted. Tag would > > > generate hidden field and a > > PropertyConversionParam > > > (new class) instance stored under the user's > > session > > > with PropertyConversionParam.getKey() used as the > > > session attribute and the hidden field name. This > > > would only be performed by the tag if the bean's > > > property type was a date AND 'dateformat' > > attribute > > > was specified. > > > > > > Scratchpad of PropertyConversionParam class: > > > > > > PropertyConversionParam { > > > > > > public static final String KEY_PREFIX = > > > "conversion-param"; > > > public static final String > > DATE_CONVERSION_PATTERN = > > > "dateConversionPattern"; > > > > > > //simple setter/getter properties > > > private String beanName; > > > private String property; > > > private String paramName; > > > private String conversionValue; > > > > > > //calculated namespace key > > > private String key = null; > > > > > > public String getKey() { > > > if (key == null) { > > > key = KEY_PREFIX + > > > String.valueOf(beanName.hashCode()) + > > > String.valueOf(property.hashCode()) + > > > String.valueOf(paramName.hashCode()); > > > } > > > return key; > > > } > > > } > > > > > > 2) Modify RequestUtils.populate: > > > * For each property that has a dateformat value > > > present remove Session PropertyConversionParam > > > attribute and do not store name/value pair in map > > > given to BeanUtils.populate method. > > > * If there is a null attribute value ignore and > === message truncated === __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]