It's not that I don't like generics -- I just don't think Component
makes sense as a generic class because it seems like the majority of
use cases don't call for specifying a model type.
Let me ask you, do you specify the type for form components even when
you're using a CompoundPropertyModel (i.e. when you're never going to
call getModel() or getModelObject() directly on those components)?
And what about MarkupContainers and other components that you usually
don't assign a model to?
-Ryan
On Mar 19, 2007, at 11:25 AM, Philip A. Chapman wrote:
Guys,
I've used generics with 2.0 at length, and absolutely love them. I
am a huge fan of catching a problem early with compile-time errors
rather than finding out later that I'm returning the wrong type
from a model or that my Formatter is expecting a different type.
Yes, for a while the angle brackets are ugly and annoying. Heck
the first time I saw C style language, I thought that all the
braces where ugly as sin. When I first began using annotations, I
found it hard to read. Now? I've used all these things and have
learned how to read them without having to stare at them a long
time. Now I can move on to using them to make my code better.
You do not *have* to use generics even with a generified
framework. You will have to do a lot of casting and get a lot of
compiler warnings, but it is not required. Nothing keeps you from
defining a variable as a ListChoice rather than
ListChoice<MyUserBean>. I, on the other hand use
ListChoice<MyUserBean> extensively. To take that away would
require that I touch a lot of code. For you, it requires that you
ignore compiler warnings.
All in all, I don't care much about the constructor change, but I
consider generics to be a must-have.
Anyway, that's my 2 cents. Your mileage may vary, of course.
On Sun, 2007-03-18 at 22:22 -0700, Ryan Holmes wrote:
Sure, but converters shouldn't necessarily be more tightly coupled
to models either. Converters might use more fine grained types
than a model, for instance (although I do see your point -- if
objects are naturally tightly coupled there's no reason to pretend
they're not). I guess I'm looking at this from a fundamentally
different point of view: I've been getting by just fine with
Wicket 1.2 (better than fine -- I freakin' love it) and haven't
once been bothered by the lack of generics. I end up with maybe
one or two casts in a page which just isn't a big deal. At the
same time, generic components seem to add little and cost a lot in
terms of productivity, readability and upgrade effort. So I
totally agree that some things are nicer with generics. But that
doesn't mean that generic components are the right design. I mean,
are there demonstrable advantages to generic components that make
Wicket a better framework and/or improve the API from a user's
point of view? Or are generic components strictly a side-effect of
generic models? -Ryan On Mar 18, 2007, at 6:35 PM, Igor Vaynberg
wrote: > 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 >> > >> > >>
-- Philip A. Chapman Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP
