Re: generics in Wicket

[Ryan Holmes]

Well, you could make getModel() and setModel() generic methods rather  
than specifying the model's type on the component. That would allow  
for generic models without generifying the entire framework to get them.

I checked out 2.0 to see how generics work inside the framework. I  
have to say it looks like some horrible angle-bracket disease has  
infected the code base ;). The heavy use of <?> and raw type  
references to component classes reinforces my opinion that components  
simply don't lend themselves to generification.

-Ryan

On Mar 18, 2007, at 5:43 PM, Eelco Hillenius wrote:

Hi Ryan,

The problem is - I found out later - that we can't really generify
models in a meaningful way without generifying components as well. At
least, I haven't found a good way.

Do you have concrete suggestions or a proposal of how we could
implement generics in a meaningful but non-obstrusive way?

Eelco


On 3/18/07, Ryan Holmes <[EMAIL PROTECTED]> wrote:
I think generic components are a mistake for several reasons. Not
only is the snippet below ugly and redundant, it doesn't even save a
cast if you're using a CompoundPropertyModel (which is the most
common case in my app). Well, I guess you save one cast, but that's
for the parent component's model, not for the form components
themselves.

At least for FormComponents, it's relatively obvious that a
component's type == its model type. But what does it mean to specify
the type for a Panel, Link, WebMarkupContainer, etc. when you're not
even going to assign a model to the component (again, a fairly common
case)? I think classes that make sense as generics don't have this
problem -- they always hold, accept or return objects of their
specified type.

A lot of this boils down to the fact that a component's type
parameter really has little to do with the component itself. It's for
the underlying model (including validation/conversion to the model's
object). Specifying the model's type in the component tightly couples
the two together, which clashes with Wicket's concept of models as
independent and dynamically resolvable objects (not to mention
clashing with MVC in general).

So, I completely agree with everything you said below and just wanted
to throw out a "-1" for generic components hopefully before a final
decision is made.

-Ryan


On Mar 6, 2007, at 9:57 PM, Eelco Hillenius wrote:

> Hi,
>
> I think we went overboard applying generics in Wicket.
>
> Things like:
> TextField<Integer> integerTextField = new TextField<Integer>(this,
> "integerProperty", Integer.class);
>
> are just horrible imo. Sure, you can do:
>
> Integer i = integerTextField.getModelObject();
>
> instead of:
>
> Integer i = (Integer)integerTextField.getModelObject();
>
> but that's about the whole great benefit of generic components  
for the
> price of about twice the verbosity.
>
> Also, calling getModelObject is the kind of convenience method that
> grew upon us but that I personally never liked. It saves an ugly  
model
> check, fine, but in general I think users should try to directly  
work
> with models and their underlying objects instead.
>
> I can see the method come in handy in list views (on ListItem),  
though
> then again, you know the model object would never be null there so
> getModel().getObject() would work as well.
>
> Anyway, what I'd like us to consider is to de-generify  
components and
> only keep it for models. For certain components (like ListView) we/
> users can decide to introduce it, but the general case would be  
to not
> to.
>
> Thoughts? Screams?
>
> Eelco