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
signature.asc
Description: This is a digitally signed message part
