[
https://issues.apache.org/jira/browse/WICKET-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
SoulSpirit updated WICKET-4930:
-------------------------------
Summary: Generified Component and Component.getInputConverter() (was:
Generified Component and Component.inputConverter())
> Generified Component and Component.getInputConverter()
> ------------------------------------------------------
>
> Key: WICKET-4930
> URL: https://issues.apache.org/jira/browse/WICKET-4930
> Project: Wicket
> Issue Type: Wish
> Components: wicket
> Affects Versions: 6.4.0, 7.0
> Reporter: SoulSpirit
> Attachments: 0001-From-Component-to-Component-T.patch
>
>
> Many years are passed since I first used Wicket and there are 2 things I've
> never really understood:
> 1. Why Component hasn't been generified (i.e. type parametrized)?
> 2. Why Component.getConverter() takes a Class<C> parameter?
> For the first question, I have the suspect the answser brings to backward
> compatibilities issues (even if Wicket project hasn't always been so much
> backward compatible between releases). The recent introduction of
> IGenericComponent is a hint.
> The answer to the second question came clear after a recent release (I don't
> remember which) that broke some of my components (I'll explain later why).
> I've always used Converters to convert the model object to a String, but I've
> learned that they are also used to convert "other" values related to the
> Component.
> For example, an AbstractChoice may have a model of type X, and at the same
> time showing values (the choices) of a different type Y. I never ever had
> this need, but I understand it's a possibility, and that it should be
> possible to set a Converter for either type X and Y.
> The problem is that the only tool Component.getConverter() has to choose
> between the available Converters is the Class<C> of the value we want to
> convert, and this isn't always enought.
> The recent Wicket release I was speaking about changed the way validation
> messages are generated, converting every message's variable (${input} and
> ${label} too) with the Component's Converter.
> If, for example, a custom Component is bound to a IModel<String> that need
> custom conversion, the same Converter is used to transform that ${label} that
> compose the validation message. And there's no way to avoid it without
> re-engineering the custom Component.
> I think is more natural to refer to a "component converter" as something that
> "converts the model to a string".
> The tipical Component.getConverter() implementation looks like this:
> public <C> IConverter<C> getConverter(final Class<C> type)
> if (MyType.class.isAssignableFrom(type)){
> return (IConverter<C>)converter;
> }else{
> return super.getConverter(type);
> }
> but I'd like to have something like this, that just converts from/to the type
> of the component's model:
> public IConverter<MyType> getInputConverter(){
> return converter;
> }
> Obviously, this syntax requires Component to be defined with a type parameter.
> The patch I've attached introduces the method
> Component#getInputConverter(Class<T>).
> I haven't removed the Class parameter present in the original #getConverter()
> method to avoid the use of reflection, but I have introduced
> FormComponent#getInputConverter() (without parameters) as a shortcut to it.
> Along with these two methods, I changed the declaration of Component to
> Component<T>, and I updated all the framework to support that type parameter,
> thus removing IGenericComponent, GenericPanel and GenericWebPage.
> The patch breaks something in the compatibility field, but I've updated all
> the tests to work correctly, and I've made most of them making use of the new
> type parameter. I'm open to discuss it in detail if someone is interested.
> Little confusion remains in the project about type parameters related to
> List<T>, List<? extends T>, ? extends List<? extends T>, Collection<T>, ... ,
> but that sort of confusion was already present and I haven't invested much
> time trying to fix it.
> This patch isn't fully polished as I haven't checked if all the classes make
> use of the new type parameter and I haven't tried it with any of my real
> projects, because I understand it will not be so easily integrated into the
> main branch. It represents just an idea to demonstrate that such a
> refactoring is possible, and it is fairly effortless (it took me about 10
> hours of work).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
