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 allow existing Converters to attempt conversion.
3) Add new DateUtil class to struts util package with methods: - java.util.Date toDate(String pattern, String value) - String toString(String pattern, java.util.Date value) Realizing the tidyness of centralizing the conversion behaviour, these methods could simply be added to the ConvertUtils.
4) Modify RequestProcessor.processPopulate
(processPopulateConversions ?):
* After call to RequestUtils.populate() remove
session attributes that begin with
PropertyConversionParam.KEY_PREFIX
* For each PropertyConversionParam that has a
non-null request parameter conversion value, call
BeanUtils.setProperty(Object, String, Object) after
convert the string date to date a java.util.Date using
DateUtil.toDate. PropertyConversionParam.getConversionValue() would
provide 'pattern' parameter while request would
provide the 'value' parameter.
* For each string --> date conversion that fails add
a ActionError instance for the property and follow
same redirect logic detailed in processValidate method
(perhaps a method extract refactoring).
Date --> String 1) add "dateformat" attribute to bean:write tag & all html input tags 2) modify tag to call DateUtil.toString if bean property is of type Date and "dateformat" attribute is not null
Please realize this is a first cut and I expect to incorporate loads of feedback prior to submitting a patch.
--- Joe Germuska <[EMAIL PROTECTED]> wrote:
At 11:23 -0700 6/27/03, Jon Wilmoth wrote:
I'm reposting as the previous attempt may have
gotten
lost in the new release excitement.
I'd like to know what the CURRENT plans are for supporting date datatypes in the framework. This means conversion of strings --> dates for FormBean population and the converse date --> string for rendering FormBean values.
I think submitting a patch would be the most
effective way to get this put into plans. But note that the
string-to-object conversion is generally handled in Commons BeanUtils, not
directly in Struts. The Struts "problem" to solve is where to specify
the date format conversion, and unless you want to support only one
date format for a whole application, how to pass date formats along to
the form population process at the right time.
How do you propose to handle the variety of possible
date formats? Between the fact that that's a mildly complicated
question and the fact that at least some Struts developers think that
you should just use String types for all text fields in your forms,
I suspect that's why you haven't seen any "official" support.
But if you submit a patch or at least start a
discussion of the implementation issues, I'm sure you'll get opinions.
There are lots of those around here ;-)
Joe
--
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "If nature worked that way, the universe would crash
all the time." --Jaron Lanier
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________ 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]
-- Ted Husted, Struts in Action <http://husted.com/struts/book.html>
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
