But what is the problem then?
You do want the textfield?
But the component isn't really in your way and does give you
getModelObject()
i don't see the point of deleting it from Component but keeping it for
pretty much everything else
johan
On 3/7/07, Jonathan Locke <[EMAIL PROTECTED]> wrote:
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.
