what about the cases where it is very nice to have?
ListView(String,IModel<T>,IModel<List<T>>)
or
DropDownChoice(String,IModel<T>,IModel<List<T>>,IChoiceRenderer<T>)
im not arguing for or against, but there are cases where it is very nice to
have them, especially for newbies. when a newbie looks at the above they
know whats going on as opposed to
DropDownChoice(String,IModel,IModel,IChoiceRenderer)
-igor
On 3/19/07, Ryan Holmes <[EMAIL PROTECTED]> 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
