the imodel wouldn't be generic in component. only in subclasses. i
actually mildly prefer total generification too, but a lot of people have
expressed annoyance at generic code bulk so i've been listening to that.
basically, getModelObject would return Object below, but ListView<T> would
return T. or that was the idea... i'm not sure if it's good. i just wanted
us to discuss it to see what's there.
Stefan Lindner wrote:
>
> Maybe I am too accustomed to generics now but I can't imagine how a
> non-generic Component class definition with a generic Model parameter can
> look like.
> Now Compinent is defined as
>
> class Component<T> ... {
> public Component(final MarkupContainer<?> parent, final String
> id, final IModel<T> model) {
> ...
> }
>
> public final T getModelObject() {
> ...
> }
>
> How should a non generic class definition look like? And pepole that don't
> like or need generics can still use the raw types.
> My preference for a strong gneric API comes from the experience I made
> when I moved from Wicket 1.2 to 2.0. The simple syntactic modifications
> for generic Components showed up several programming errors that we
> otherwise had to debug during runtime of the application. It also showed
> up some design problems of our applicatioin. So a strong generic API may
> took a little bit more time in developing an application but it saves much
> more time in debugging.
>
> Stefan Lindner
>
>
>
--
View this message in context:
http://www.nabble.com/generics-in-Wicket-tf3360271.html#a9356570
Sent from the Wicket - Dev mailing list archive at Nabble.com.
