> 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]
