I think this approach is a nice compromise between the two camps.
Perhaps we should put the results of our disucssion(s) on the wiki
outlining the pros/cons of each approach and our justification for
choosing one over the other. If folks want to have generified panels
or whatever, it'd be trivial for them to create subclasses like this
(provided we make the appropriate methods non-final):
public class GenericPanel<T> extends Panel
{
...
}
Perhaps that could go on the wiki, too
On Wed, Jun 4, 2008 at 7:53 AM, Matej Knopp <[EMAIL PROTECTED]> wrote:
> The generics discussion seems to have no end. But one thing seems to
> be quite apparent to me. Most people using Wicket 1.4 on real project
> aren't really happy with it. But everyone agrees that there are
> benefits too. So say we went the way of generics for models only, i.e.
> Component getModel would return IModel<?> and getModelObject would
> return Object. We would also leave get/setModel and get/setModelObject
> non final (with a big fat javadoc explaining why) so that we would
> allow generified subclasses where it makes sense (ListView/ListItem).
> What potential caveats would this approach have? (Except maybe for the
> obvious less strict type checking)
>
> -Matej
>
