the thing is the model ties into a few places in the component
for example IConverter Component.getConverter(). it would be nice to say new
WebMarkupContainer<Person> { IConverter<Person> getConverter() {...}}
things like that
-igor
On 3/18/07, Eelco Hillenius <[EMAIL PROTECTED]> 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
>
>
