In those few instances where i had to override getConverter i didn't
care much about the input param. But if we want to support returning
multiple converters i have a slight preference for only keeping one
method and have the checkbox return super if a non boolean class is
used as input.
Maurice
On Sun, May 25, 2008 at 11:28 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
> i refactored generics in iconverterlocator to how they should be. i
> did see something pretty interesting though: we used to have
> component.getconverter() which we refactored into
> component.getconverter(class) to support multiple converters. but then
> checkbox does this:
>
> public <X> IConverter<X> getConverter(Class<X> type)
> {
> return (IConverter<X>)BooleanConverter.INSTANCE;
> }
>
> which seems wrong to me because if i say getconverter(integer.class) i
> expect to get a converter that can converter integers not booleans.
>
> so here is what i propose:
>
> formcomponents are "single type" components where the type is well
> known. so we should probably have:
>
> class formcomponent {
>
> public FINAL <X> IConverter<X> getConverter(Class<X> type) {
> if (type==well_known_formcomponent_type) {
> return getConverter();
> } else { return super.getConverter(type); }
> }
>
> public IConverter<T> getConverter() {
> return super.getConverter(well_known_formcomponent_type);
> }
> }
>
> that way we still have getConverter() without a type param that can
> easily be overridden by components
>
> or another solution is to implement checkbox.getconverter(class<T>
> type) like this:
>
> if (Boolean.class.isassignablefrom(type)) {
> return BooleanConverter.instance; }
> else { return super.getconverter(type); }
>
>
> thoughts?
>
