Craig McClanahan wrote:
Blame backwards compatibility. By the time this issue was raised,
there were huge numbers of applications already dependent on the
previous behavior, which would have been broken by a change.
However, this shouldn't have *any* impact on "incorrect values in
forms". If you are following the recommended design pattern of using
String fields in your form beans, it shouldn't trouble you.
In fact I'm a bit confused what exactly is the recommended design
pattern in this case ...
My conclusion is really to use Strings, or even mapped forms.
If you want a default Date or some other default than provide that
before going to your form...or if after it submits and you see a null,
then provide the default. You could of course register your own
converter to provide a default for when a Date is null- but I would
NOT do this.
I thought about such variant but I don't find it good as well, but may
be this is the less harmful or let's say less painful.
Dates and Times and Timestamps were *deliberately* omitted from the
default set of conversions performed by BeanUtils. The reason is
simple ... such conversions are Locale specific, and BeanUtils has not
This is clear for me, but at least default locale can be covered. But I
think this is not for this thread, it's out of Struts mailing list scope.
Sorry if this writings sound as complain - this the last think I want to
make. Just after reading a lot of "advices" I found let's say my own way
to work with Struts, and IMHO this is a sign of mature framework
(because there is no only one way, it gives choices and I have to decide
which trade-offs to take.
concept (in its standard APIs at least) of what a "Locale" is. You
can use the converters in "org.apache.beanutils.locale" for dealing
with this sort of thing, but that came later than the basic Struts
architecture.
Craig
Regards
Borislav
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
