Help the Apache Wicket team to determine the future of your Wicket based web application development. We have released our third and hopefully final milestone release of our Java 5 based web framework and are anxious to receive feedback on our use of generics.
This release is our final take on how to apply generics to our codebase with restraint. We hope to provide an elegant programming model without having to specify generic parameters everywhere, while still providing type safety when you need it.
A significant change from the earlier Wicket 1.4 milestone versions is that Component is no longer generified. This means that Component and most of its subclasses in Wicket do not take a class-level type parameter. Some Component subclasses remain generified, such as Link, Form, FormComponent, ListView, etc. You can read more details regarding these changes here:
We feel that this might provide a good middle ground between being unable to add typing to IModel on one hand and a proliferation of unneeded typing information on modelless components on the other hand. Your feedback is appreciated!
Download Wicket 1.4-m3 now and help us decide whether to tone down, remove or increase the application of Java 5 generics to our API. We have started the discussion on the user mailing list:
Eager people click here to download the distribution, others can read further:
We thank you for your patience and support.
The Wicket Team
That thread is slightly going overboard and I don’t want to register on Nabble (storing passwords in cleartext, bah), so I’ll share my thoughs on the m3 here:
I just updated my current project to see what will happen. Its not encouraging. My impression is that generified models are worthless without generified components. Most of the time adding the type parameter gains nothing then to satisfy the compiler. The only place where I can remove a cast is in ListView’s populateItem method, where I can use getModelObject directly, without having to cast first. All in all I have to add code to get very barely more type safety.
In the case of PropertyModel I gain nothing, as the constructor still takes Object, while I don’t ever call the generified get/setObject methods myself.
I’m having two TextField subclasses to implement my own Converter for certain fields. Just registering a new Converter doesn’t do the trick, as I need to have a special converter for one Long field. Without generics I can overwrite the getConverter() method, with generics I can’t, as getConverter doesn’t care for the component type, just for the type of the class being passed. So I’d replace Object with X and still have to cast to Long.
Having generic Links doesn’t help either – my Links all interact with the parent component’s model object, usually a page or panel. Setting models to each and every nested components seems like a waste of code as using the parent model object works fine.
I hope this helps in deciding how to move on!
Regards
Jörn