I agree the proposal was not a wholistic solution, but
it did address an very real issue with a "doable"
timeframe. Since every application I've every been
involved with has had to solve date conversions, I
believe this is an ideal extension to the framework.
It should be noted that date support is provided
through the default converters
(org.apache.commons.beanutils.converters.SqlDateConverter,
org.apache.commons.beanutils.converters.SqlTimeConverter,
and
org.apache.commons.beanutils.converters.SqlTimestampConverter)
but they required a fixed input format that may not
work with all application. I welcome a more universal
solution (and have some thoughts for such outlined
below), but I am afraid of getting into a design that
due to it's numerous touch points never gets
implemented. Perhaps I've just listened to one too
many "Agile Methodology" pitches ;)
Due to the fact conversion patterns (date atleast) can
be dynamic (user preference for date formatting,
etc.), I would imagine the taglibs would still have to
have the opportunity to override the static XML
default definition.
I think expanding the Converter interface to accept
"configuration" parameters would allow for a more
robust ConvertUtils. Unfortunately, to get to the
conversion (from Struts), you have to get through the
BeanUtils.populate method and I do not know if it's at
this point this "Field Descriptor" object comes into
play. I do like the relative simplicity of the
current method. Prior to Struts existence (almost
unimaginable!) myself and another developer built a
MVC implementation for webapps that had just such an
object and the ActionForm was merely an container for
related "ActionField"s. This had it's problems as it
oversimplified the relationship between
fields...perhaps a hybrid is instore?
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?
--- 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
> 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]
>
__________________________________
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]
