Re: Fw: [Springframework-developer] BeanWrapperImpl abstraction

[Tom T. <tom...@pr...>]

Juergen,

> The change should be completely backward-compatible. Only if you
> specified a
> wrong type on registration (i.e. not the target type that the editor will
> actually create), the stricter check will now show. As passing in such a
> wrong type is a misuse of the API, this is even desirable, I guess.

When you register a custom editor "for a certain type", do you register
it for the type of the property or the actual type of the value?

For example, I'm not sure this is desired behavior:

private void test() {
    long now = 1087206665855L;
    System.out.println(getValue(new Date(now), null));
    // prints "14/06/2004"
    System.out.println(getValue(new Timestamp(now), null));
    // prints "2004-06-14 11:51:05.855"
    // shouldn't this be "14/06/2004" as well?
    System.out.println(getValue(new Timestamp(now), "date"));
    // prints "14/06/2004"
}

private Object getValue(Date date, String property) {
    DateBean dateBean = new DateBean();
    dateBean.setDate(date);
    DataBinder binder = new DataBinder(dateBean, "dateBean");
    binder.registerCustomEditor(Date.class, property,
            new CustomDateEditor(new SimpleDateFormat("dd/MM/yyyy"),
            true));
    return binder.getErrors().getFieldValue("date");
}

public class DateBean {
    private Date date;

    public Date getDate() {
        return date;
    }

    public void setDate(Date date) {
        this.date = date;
    }
}

Suppose I have a form in a web application to edit an object, with a
Controller extending from AbstractFormController. The form backing
object has java.util.Date properties, so I register a custom editor for
all Date properties (property = null) in initBinder, like above.

When the form backing object is the result of a database query, its
java.util.Date properties actually contain java.sql.Timestamp objects,
which are then incorrectly displayed in the form, because the property
editor is not used, unless I register a custom editor for every
individual property...
Of course, I don't want to _know_ that the Date properties are actually
Timestamps, so I don't want to register a custom editor for all
Timestamp properties...

Is this the intended behavior or a bug?

Kind regards,
Tom.