You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Jon Wilmoth <jo...@yahoo.com> on 2003/07/01 19:56:51 UTC

[BeanUtils & Struts]RE: Support for Date datatypes!!!

I'm cross posting due to the interproject
dependencies.  It has been requested that the Struts
framework provide more robust support for
submitting/displaying UI fields (dates as a prime
example) that have string-->object conversion
requirements not currently covered by the BeanUtils
project leveraged by Struts.  I suggested that the
exiting Converter interface be expanded to accept
parameters (Map of configurations?) to allow custom
converters to be more flexible in their
implementations.  However, the Struts API accesses the
ConvertUtils through the BeanUtils.populate method and
that would also require modification.  Because of the
multiplicity of fields handled by the populate method,
perhaps a new datastructure
(PropertyChangeDefinition?) is appropriate for
communicating the new value, the target datatype, a
converter, and perhaps some conversion parameters?


--- Jon Wilmoth <jo...@yahoo.com> wrote:
> Date: Tue, 1 Jul 2003 10:45:44 -0700 (PDT)
> From: Jon Wilmoth <jo...@yahoo.com>
> Subject: [BeanUtils & Struts]RE: Support for Date
> datatypes!!!
> To: Struts Developers List
> <st...@jakarta.apache.org>
> 
> I did investigate registering "custom" converters. 
> Unfortunately, anything that would support
> non-hard-coded conversion patterns will require
> either
> a mixed paradygm usage (i.e passing a complex object
> that contains the value to convert and all
> convertion
> configuration instead of simply the value to be
> converted) of the existing Converter.convert
> interface
> or additional parameters.  Since I think everyone
> can
> agree that the first option is confusing and should
> be
> avoided when possible the remaining option is to
> modify/extend the interface.  I agree this should be
> communicated within the BeanUtils developer mailing
> list and will cross post this in hopes of getting
> further creative approaches to the problem.  Because
> Struts will be responsible for providing the means
> to
> invoke the conversion (and much more) I do feel it
> is
> appropriate for this list to continue to discuss the
> Struts/BeanUtil interaction necessary for this
> functionality.
> 
> --- Wendy Smoak <We...@asu.edu> wrote:
> > 
> > [Not a developer, but I've been following this
> > because I ran into the date
> > problem early on.]  I use BeanUtils.copyProperties
> > to move things back and
> > forth from ActionForms (all String properties) and
> > my DTO's, as shown in the
> > struts-example webapp.  At some point I thought
> > needed a Java "Date" object
> > in the DTO (that requirement went away with
> further
> > development).  And the
> > existing SQL formatted Date converter wasn't going
> > to work, my database
> > doesn't understand that format.
> > 
> > What was suggested to me is writing and
> registering
> > my own Converter with
> > BeanUtils.  I don't think I went through with it,
> > but that made perfect
> > sense to me.  IMO, Struts shouldn't get involved
> > with Date conversions,
> > that's already the job of Commons BeanUtils.
> > 
> > -- 
> > Wendy Smoak
> > Applications Systems Analyst, Sr.
> > Arizona State University, PA, IRM 
> > 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Re: [BeanUtils & Struts]RE: Support for Date datatypes!!!

Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
(without wanting to sound too negative) since extending the interface 
would break backwards compatibility i'd say that there would have to be 
some very, very good reasons for doing so. in addition, i'd say that 
everyone would have to be convinced that this is the right change to make.
  often this is a hard call for library code.

i don't really understand the problem in depth (maybe someone could 
enlighten me perhaps by providing some examples) but i'd be more inclined 
to think about extensions along the lines proposed recently by Eric Pabst 
than by changing the basic interfaces. (more about this in another email.)

i would be interested to hear what other people think about this.

- robert

On Tuesday, July 1, 2003, at 06:56 PM, Jon Wilmoth wrote:

> I'm cross posting due to the interproject
> dependencies.  It has been requested that the Struts
> framework provide more robust support for
> submitting/displaying UI fields (dates as a prime
> example) that have string-->object conversion
> requirements not currently covered by the BeanUtils
> project leveraged by Struts.  I suggested that the
> exiting Converter interface be expanded to accept
> parameters (Map of configurations?) to allow custom
> converters to be more flexible in their
> implementations.  However, the Struts API accesses the
> ConvertUtils through the BeanUtils.populate method and
> that would also require modification.  Because of the
> multiplicity of fields handled by the populate method,
> perhaps a new datastructure
> (PropertyChangeDefinition?) is appropriate for
> communicating the new value, the target datatype, a
> converter, and perhaps some conversion parameters?
>
>
> --- Jon Wilmoth <jo...@yahoo.com> wrote:
>> Date: Tue, 1 Jul 2003 10:45:44 -0700 (PDT)
>> From: Jon Wilmoth <jo...@yahoo.com>
>> Subject: [BeanUtils & Struts]RE: Support for Date
>> datatypes!!!
>> To: Struts Developers List
>> <st...@jakarta.apache.org>
>>
>> I did investigate registering "custom" converters.
>> Unfortunately, anything that would support
>> non-hard-coded conversion patterns will require
>> either
>> a mixed paradygm usage (i.e passing a complex object
>> that contains the value to convert and all
>> convertion
>> configuration instead of simply the value to be
>> converted) of the existing Converter.convert
>> interface
>> or additional parameters.  Since I think everyone
>> can
>> agree that the first option is confusing and should
>> be
>> avoided when possible the remaining option is to
>> modify/extend the interface.  I agree this should be
>> communicated within the BeanUtils developer mailing
>> list and will cross post this in hopes of getting
>> further creative approaches to the problem.  Because
>> Struts will be responsible for providing the means
>> to
>> invoke the conversion (and much more) I do feel it
>> is
>> appropriate for this list to continue to discuss the
>> Struts/BeanUtil interaction necessary for this
>> functionality.
>>
>> --- Wendy Smoak <We...@asu.edu> wrote:
>>>
>>> [Not a developer, but I've been following this
>>> because I ran into the date
>>> problem early on.]  I use BeanUtils.copyProperties
>>> to move things back and
>>> forth from ActionForms (all String properties) and
>>> my DTO's, as shown in the
>>> struts-example webapp.  At some point I thought
>>> needed a Java "Date" object
>>> in the DTO (that requirement went away with
>> further
>>> development).  And the
>>> existing SQL formatted Date converter wasn't going
>>> to work, my database
>>> doesn't understand that format.
>>>
>>> What was suggested to me is writing and
>> registering
>>> my own Converter with
>>> BeanUtils.  I don't think I went through with it,
>>> but that made perfect
>>> sense to me.  IMO, Struts shouldn't get involved
>>> with Date conversions,
>>> that's already the job of Commons BeanUtils.
>>>
>>> --
>>> Wendy Smoak
>>> Applications Systems Analyst, Sr.
>>> Arizona State University, PA, IRM
>>>
>
>
> __________________________________
> Do you Yahoo!?
> SBC Yahoo! DSL - Now only $29.95 per month!
> http://sbc.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org