Re: generics in Wicket

> 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