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
