for property binding. It saves a huge amount of development time.
lot of generic classes, etc. and only have a handful of
@SuppressWarnings("unchecked") annotations. If you look at how/where
that type. Therefore, there's rarely a need to use the raw versions
add any new functionality. There's nothing you can do with generics
a matter of style. It's tough to come up with quantitative points for
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 >>
>> <
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
> -- Philip A. Chapman Desktop and Web Application Development:
> Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP
signature.asc (196 bytes) 