So it would be no generics or it would be: MyComponent<CompoundPropertyModel> mycom = new MyComponent<CompoundPropertyModel>();
and I was saying that the suppress *should not* be in the API because people need the ability to control that sort of thing at their own code level, which should address your issue. - Brill Pappin On Tue, Jun 3, 2008 at 11:54 PM, Mike Comb <[EMAIL PROTECTED]> wrote: > Well, in our case it would almost never be: > > MyComponent<MyModel> mycom = new MyComponent<MyModel>(); > > We don't have many of our own models, we use CompoundPropertyModel pretty > much exclusively (wrapping DAOs or javabeans). So the verbosity doesn't > benefit us much. Also, the vast majority of our components don't have a > model. We generally have a page containing one or more forms with a > CompoundPropModel on each form. Having generics (particularly if they are > just something like <Void>) on every other object in the page is messy and > confusing in my mind. > > Telling people to use suppress annotations is not a good solution either, we > want those warnings for other things in our code (Collections, etc). > > -Mike > > On Jun 3, 2008, at 8:11 PM, Brill Pappin wrote: > >> I guess I'm not understanding why people feel strongly against generics in >> the components. >> >> The model is going to use them for the data they contain, but the >> component >> would use them for the model it uses: >> >> MyModel<String> mymodel = new MyModel<String>(); >> >> MyComponent<MyModel> mycom = new MyComponent<MyModel>(); >> >> And that's all you would ever see of the generics unless you actually >> override one of the components methods (as in a button onclick). >> >> To top it off, I'm not even sure you would have to specify the generics >> for >> the component (not up on my generics coding)... But if the warning was >> bugging you, you could simply use a suppress annotation (suppress should >> absolutely not be in the API). >> >> More verbose? Yes... Not by much, but it is... However the advantages >> gained >> in terms of readability and type safety are enormous. >> >> - Brill Pappin >> >> >> -----Original Message----- >> From: Mike Comb [mailto:[EMAIL PROTECTED] >> Sent: Tuesday, June 03, 2008 4:39 PM >> To: users@wicket.apache.org >> Subject: Re: users, please give us your opinion: what is your take on >> generics with Wicket >> >>> [X ] Can best be done in a limited fashion, where we only generify >>> IModel but not components. I care more about what generifying can do >>> for API clarity (declaring a component to only accept certain models >>> for instance) than static type checking. >> >> I've spent a couple of afternoons trying to move our app to m1. My >> experience has been that generics on components are absolutely not worth >> it >> for our use cases. I love generics on objects that directly hold data >> (IModel), but they are too verbose and not very useful for objects that >> are >> a few levels removed from the actual data. >> >>> [X ] Whatever choice ultimately made, I'll happily convert/ start >>> using 1.4 and up. >> >> "Happily" probably isn't the word I'd chose, but we'll move to 1.4 >> eventually regardless of the decision made. >> >> -Mike >> >> -- >> Mike Comb >> Director of Engineering >> SoftCoin, Inc >> [EMAIL PROTECTED] >> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [EMAIL PROTECTED] >> For additional commands, e-mail: [EMAIL PROTECTED] >> > > > > -- > Mike Comb > Director of Engineering > SoftCoin, Inc > [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
