Re: generics in Wicket

>
> 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
> >> <eelco.hillenius@...> 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 <ryan@...> 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
>
>