On 7/11/05, Borislav Sabev <[EMAIL PROTECTED]> wrote: > Rick Reumann wrote: > > > > > You shouldn't want a "default" at all provided by BeanUtils for cases > > where it can be null! You are using the anomoly of the way Integer is > > working and wanting to propogate that poor solution. null should be > > null.. it shouldn't be 0 or some default Date if null is provided. > > > Yes, this is the strange point. So null value doesn't have the same > semantic for Integer, Double etc. and Date, so I find this a bit > confusing ...this means at least different approach in handling the > incorrect values in forms.
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. > > > 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 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 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
