[ https://issues.apache.org/jira/browse/WICKET-4930?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13534026#comment-13534026 ]
Carl-Eric Menzel commented on WICKET-4930: ------------------------------------------ To clarify: The reason I don't like the proposal is that it would *require* all components to have a type parameter, but for most it doesn't make sense to have one. Some may be good with one, another with several, another with none. > 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 > Reporter: SoulSpirit > Priority: Minor > Fix For: 7.0 > > 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