Thanks for the feedback Philip.
I use property models, especially CompoundPropertyModel, extensively
and wouldn't consider using a framework that didn't have good support
for property binding. It saves a huge amount of development time.
The reason I don't think it's sufficient to say "use
@SuppressWarnings" is because 1) a well-designed framework shouldn't
require you to suppress compiler warnings in the first place (at
least not very often) and 2) unless I'm going to apply that
annotation on an almost line-by-line basis, it can hide warnings that
I want to see.
We've been using generics at my work for quite a while now, written a
lot of generic classes, etc. and only have a handful of
@SuppressWarnings("unchecked") annotations. If you look at how/where
generics have been applied in the JDK, they tend to be on classes
that do little more than hold and operate on objects of their
declared type or are otherwise naturally strongly associated with
that type. Therefore, there's rarely a need to use the raw versions
of those classes.
Component, on the other hand, mostly consists of methods that do not
use the declared type and I think typical usage (which probably
involves a lot of property models and markup containers) leads to a
majority of Component instances deriving no benefit from specifying a
model type.
I don't think your tool analogy holds up here, because generics don't
add any new functionality. There's nothing you can do with generics
that you can't do without them.
Unfortunately, I think like/dislike of generics in Wicket is largely
a matter of style. It's tough to come up with quantitative points for
or against.
-Ryan
On Mar 20, 2007, at 3:37 AM, Philip A. Chapman wrote:
Ryan,
I do not use property models much, so that's part of the difference
between our points of view (our coding styles). However, I do have
at least one page that uses one. In that case, I forgo generics.
I define raw types and set @SuppressWarnings("unchecked") on the
methods that access them:
JTextField tf = new JTextField(this, "stringProperty");
I would like to make the point that when I do use PropertyModels, I
usually throw away my component anyway (I don't usually assign it
to a variable) because I only really care about the Model and the
data in it anyway. The above code snippet was just an example.
The @SuppressWarnings annotation tells the compiler to shut up and
not bother me about it 'cause I know what I'm doing. The case that
I alluded to and Ivan asked about specifically is "What about those
components where generics really does matter?" Two components that
he suggested really need generics are DropDownChoice and ListView.
There are others, but this raises a point. I think that the
problem that the wicket devs ran into early on is that either all
components are generified or none (because of the models).
I think that my statement before is still a valid and is
strengthened above. If generic components are not appropriate for
the code that you are writing, don't use them. It's OK. It's
better for you to have a torx screwdriver in our common toolbox
that you seldom use than to throw it out and I have non, but need
it daily.
Thanks,
On Mon, 2007-03-19 at 22:03 -0700, Ryan Holmes wrote:
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
-- Philip A. Chapman Desktop and Web Application Development:
Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP
