Re: users, please give us your opinion: what is your take on generics with Wicket
no worries, i wasnt holding my breath. its just that when i make sweeping statements i tend to have something to back them up that other people can see... -igor On Tue, Jun 3, 2008 at 8:19 PM, Brill Pappin [EMAIL PROTECTED] wrote: You will wait a long time for an example generated from the API would be different in such and such a case, based on an opinion. If your really all that interested you could start from scratch using generics and see what came out. Let me know if you do, because I'd be interested to see if my opinion held any merit. However, if your interested in why I said that in the first place, then I can explain that. I don't know if you have every done true TDD (most people can't or think they can), but it actually changes your code and the way you write it. Starting with 2 users of your code makes a significant impact on what it looks like in the end. I applied the same thoughts to using generics from the start, and realized the API would likely be a bit different. Exactly how much, I wouldn't presume to guess. - Brill Pappin -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 11:03 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket sorry, still waiting for an example here... -igor On Tue, Jun 3, 2008 at 7:53 PM, Brill Pappin [EMAIL PROTECTED] wrote: Actually, i did not say ... say that wicket api needs a radical refactoring in order to support generics what I actually said was I think that if Wicket had been written with generics from the beginning, the API would be different. No radical refactoring required was mentioned :) Big difference... It would be WAY too much work to rewrite it now, and I think your right that it can be implemented fairly well without too much impact on the users. - Brill Pappin -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 12:21 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket you made a radical statement, just wandering if there is anything concrete you can back it up with. in my head the generics have very little effect on the actual api design so i am wandering what prompted you to say that wicket api needs a radical refactoring in order to support generics - which essentially are little more then metadata. -igor On Mon, Jun 2, 2008 at 8:50 PM, Brill Pappin [EMAIL PROTECTED] wrote: So am I :) I think that just like TDD generates a whole new structure to your code (IMO a better one) that implementing generics at the start would have produced something a bit different. - Brill Pappin -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:42 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket im really curious to hear what these changes would be... -igor On Mon, Jun 2, 2008 at 8:25 PM, Brill Pappin [EMAIL PROTECTED] wrote: I think... We should be able to use the untyped variants, but the explanations for why that won't work directly was valid. So on to you're A/B question. I don't think it matters much... The people doing things inline are going to use that method anyway and generics won't hurt them, but the usefulness to people who write more extensive application is likely more important (if its that simple it doesn't matter much, if its complicated then it is and can be used). Allow me to digress. I think that if Wicket had been written with generics from the beginning, the API would be different... And that is the root of the problem. I think that maybe a concerted refactoring effort *must* allow the API to change (call it wicket 2.0 for all of us old struts users) in order for things to work out properly. I don't actually think that heavy a refactoring would be such a bad thing. I love what Wicket has done, but I think it could be less black-boxy as well. - Brill -Original Message- From: Stefan Lindner [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 12:13 PM To: users@wicket.apache.org Subject: AW: users, please give us your opinion: what is your take on generics with Wicket Brill Pappin wrote I don't know, I think the discussion is going *toward* generics. Frankly I can't even see why its an issue at all, the language has evolved and uses them... Why would Wicket not also use them its inline with the current state of the language? There is no reason that people who can't get their heads around Generics can't use the older releases that don't include it, but IMO any java developer who doesn't get generics yet better make some time to learn, because like it or not, they *will* be dealing with them. I agree totally with you. My expericence with Generics over
Re: users, please give us your opinion: what is your take on generics with Wicket
Well, in our case it would almost never be: MyComponentMyModel mycom = new MyComponentMyModel(); 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: MyModelString mymodel = new MyModelString(); MyComponentMyModel mycom = new MyComponentMyModel(); 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Tue, Jun 3, 2008 at 8:54 PM, Mike Comb [EMAIL PROTECTED] wrote: Well, in our case it would almost never be: MyComponentMyModel mycom = new MyComponentMyModel(); 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. Yep. Telling people to use suppress annotations is not a good solution either, we want those warnings for other things in our code (Collections, etc). Yep. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
i think we should have qualified this rfi with a requirement that responders use 1.4 on a non-trivial project...these things only become apparent from real-world day-to-day usage. anything else is pretty much speculation. -igor On Tue, Jun 3, 2008 at 10:31 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 8:54 PM, Mike Comb [EMAIL PROTECTED] wrote: Well, in our case it would almost never be: MyComponentMyModel mycom = new MyComponentMyModel(); 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. Yep. Telling people to use suppress annotations is not a good solution either, we want those warnings for other things in our code (Collections, etc). Yep. Eelco - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [X] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Didnt you encounter the big thread (at least 100 messages) where we discussed/voted going to 1.4? (and cool down dev on 1.3) On 6/1/08, Ayodeji Aladejebi [EMAIL PROTECTED] wrote: scan this user forum, you will realize that there is no high demand for generics in wicket from users. I am yet to see one user or thread here of wicket users screeming out for generics addition. I think users has been doing just fine without it at least speaking for myself. Anything more than IModel, I wont upgrade to 1.4 as well +1 for IModels only as for as I am concerned, annotations are better 1.5 additions than generics. generics is just awful On 6/1/08, atul singh [EMAIL PROTECTED] wrote: 1) [ 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. *Reason::* I think generifying data-structure/models is what is sustainable. Components can become too complicated when gentrified..and who know how far wicket wants to go!! 2) [X] I definitively won't be using 1.4. if Wicket doesn't go for my preference. On Mon, Jun 2, 2008 at 2:14 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] 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. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* 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. 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [X2] 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 would prefer to have models and components generified, however if this makes the API too verbose or cumbersome to use then I prefer to fall back to only generified models. At one point someone suggested a wiki page outlining the difficulties with generics, does such a page exist? 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* 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. 2) How strongly do you feel about your choice above? [ X ] Whatever choice ultimately made, I'll happily convert/ start Thijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* 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. 2) How strongly do you feel about your choice above? [ X] Whatever choice ultimately made, I'll happily convert/ start Dipu
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [x] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. I had a production quality project with the old 2.0 branch (downgraded it) and that worked just fine and very intuitive, I was very bummed at the time I had to add all these hideous type casts. I do not understand the fuss about generifying everything, I did not have ANY problems using the generics in my production project (which consists of about 30 wicket classes) and it was not a simple crud app, I did some funky wicket stuff with this project (loads of panels, fragment, own custom component, ajax) and it all just worked. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. Wouter de Vaal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. This is the only solution that makes sense, the other options are either a partial solution (which is a *very, very* bad thing, mixing generic with non-generic code INSIDE a framework!?!?) or no solution at all (which has my preference over a partial solution, since at least it is concise). 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. Seriously, no generics at all is better than a partial solution. Since upgrading involves more issues than generics alone, I may rethink only... If the decision to upgrade boils down to this issue, then I won't. Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [x] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [x] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. Verbose VS Clarity, Clarity wins hands down. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Sunday, June 01, 2008 4:45 PM To: wicket user list Subject: users, please give us your opinion: what is your take on generics with Wicket Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] 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. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
I agree with Antoine. Guðmundur Bjarni Antoine van Wel wrote: 1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. This is the only solution that makes sense, the other options are either a partial solution (which is a *very, very* bad thing, mixing generic with non-generic code INSIDE a framework!?!?) or no solution at all (which has my preference over a partial solution, since at least it is concise). 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. Seriously, no generics at all is better than a partial solution. Since upgrading involves more issues than generics alone, I may rethink only... If the decision to upgrade boils down to this issue, then I won't. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17596960.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* 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. 2) How strongly do you feel about your choice above? [X ] I might rethink upgrading if my choice doesn't win. We do almost all our frontend stuff with Wicket. Our developers think that the full generification will have a significant impact on ease of use and speed of development, whereas they don't see the advantages of fully typed components. regards, Wouter -- Wouter Huijnink Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
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. [ x ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. It would also be nice if the .add() and others methods on components could return the type of component it is rather than just a Component object. eg you cant do 'new TextArea(...).add(some behavior).setRequired(true) because the add behaviour method returns a Component not a TextArea and setRequired is not available on Components. Thanks -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* 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. Component generification seems a little over the top with little value. It seems that generics in the models and collections only should be sufficient. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. Any use of generics is better than versions 1.4 using no generics -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602015.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
why are you contradicting yourself? To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. if you have just IModel then you will have to cast.. getModelObject will always return just Object then. about: new TextArea(...).add(some behavior).setRequired(true) this can be done but then we have to override some methods of component and then return another type The problem is that this could result in us lifting a final where we dont want to.. But this is outside the scope of generics johan On Mon, Jun 2, 2008 at 3:26 PM, richardwilko [EMAIL PROTECTED] wrote: [ 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. [ x ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. It would also be nice if the .add() and others methods on components could return the type of component it is rather than just a Component object. eg you cant do 'new TextArea(...).add(some behavior).setRequired(true) because the add behaviour method returns a Component not a TextArea and setRequired is not available on Components. Thanks -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Should be avoided, definitly. All this generics stuff is ruining my wicket experience. 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602297.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Should be avoided, definitly. All this generics stuff is ruining my wicket experience. 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602298.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
ok maybe i misread this :
'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.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into a
model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form)
{
EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any point to
using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I want
is
to not have to do casting when I'm using models, .getModelObject() should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string.
if you have just IModel then you will have to cast.. getModelObject will
always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of component
and
then return another type
The problem is that this could result in us lifting a final where we dont
want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ 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.
[ x ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I want
is
to not have to do casting when I'm using models, .getModelObject() should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string. It
would
also be nice if the .add() and others methods on components could return
the
type of component it is rather than just a Component object. eg you cant
do
'new TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired is
not
available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602507.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [x] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [x] I definitively won't be using 1.4. if Wicket doesn't go for my preference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Goes to show you that people have a tendency to reject things that they
do not understand rather than put in the effort :o)
-Original Message-
From: richardwilko [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:21 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
ok maybe i misread this :
'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.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into
a model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form) {
EmailFormModel emailFormModel = (EmailFormModel)
form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any
point to using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the listItem
model object to a string.
if you have just IModel then you will have to cast.. getModelObject
will always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of
component and then return another type The problem is that this could
result in us lifting a final where we dont want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ 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.
[ x ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the listItem
model object to a string. It would also be nice if the .add() and
others methods on components could return the type of component it is
rather than just a Component object. eg you cant do 'new
TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired
is not available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is
-your-take-on-generics-with-Wicket-tp17589984p17601296.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17602507.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
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]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 10:21 AM, richardwilko
[EMAIL PROTECTED] wrote:
ok maybe i misread this :
'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.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into a
model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form)
{
EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject();
is what I would like to see.
generic components im not bothered about.
Using generics will do away with the casting, but only if you
genericize Component. Merely genericizing IModel won't get rid of the
casting by itself.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Ok you example doesnt work..
You will need to cast there
Then IModel only only helps describing the constructor. After that you loose
the generics or you have to ofcourse keep the models and dont work anymore
directly with the components
So if we only do IModel and not component
then this will need casting or supresswarnings:
TextField tf = new TextField(id, new ModelStirng(myString));
tf.getModelObject() will return Object you need to cast to String.
tf.getModel() will return IModel? so you need to cast it and supress
warnings and that kind of stuff.
So to keep the type safety you have to do this:
ModelString model = new ModelStirng(myString);
TextField tf = new TextField(id,model );
model.getObject() this will return a String..
johan
On Mon, Jun 2, 2008 at 4:21 PM, richardwilko [EMAIL PROTECTED]
wrote:
ok maybe i misread this :
'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.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into a
model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form)
{
EmailFormModel emailFormModel = (EmailFormModel)
form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any point
to
using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I want
is
to not have to do casting when I'm using models, .getModelObject() should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string.
if you have just IModel then you will have to cast.. getModelObject will
always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of component
and
then return another type
The problem is that this could result in us lifting a final where we dont
want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ 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.
[ x ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I want
is
to not have to do casting when I'm using models, .getModelObject()
should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string. It
would
also be nice if the .add() and others methods on components could return
the
type of component it is rather than just a Component object. eg you
cant
do
'new TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired is
not
available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602507.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
yes thats why i am against Referendums (politically) :)
On Mon, Jun 2, 2008 at 4:27 PM, Hoover, William [EMAIL PROTECTED] wrote:
Goes to show you that people have a tendency to reject things that they
do not understand rather than put in the effort :o)
-Original Message-
From: richardwilko [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:21 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
ok maybe i misread this :
'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.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into
a model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form) {
EmailFormModel emailFormModel = (EmailFormModel)
form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any
point to using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the listItem
model object to a string.
if you have just IModel then you will have to cast.. getModelObject
will always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of
component and then return another type The problem is that this could
result in us lifting a final where we dont want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ 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.
[ x ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the listItem
model object to a string. It would also be nice if the .add() and
others methods on components could return the type of component it is
rather than just a Component object. eg you cant do 'new
TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired
is not available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is
-your-take-on-generics-with-Wicket-tp17589984p17601296.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17602507.htmlhttp://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602507.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
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]
Re: users, please give us your opinion: what is your take on generics with Wicket
I think its not quite that simple. Certainly both sets of components should use generics (silly to have a partial solution) but how its done is vital so that it doesn't become a huge mess. I'm one of the adopters of the M1 release and I've found it quite difficult to keep things straight sometimes. - Model objects should allow any generic needed (due tot he nature of a model). - Components should be specific about the generics they accept i.e. instance of model etc. makeing the generics clean will help us keep our code clean. - Brill Pappin Eelco Hillenius wrote: We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602906.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
I'd really like to know how it's ruining my wicket experience? Can you please elaborate? I agree that the M1 release of 1.4 was less than optimum, but not having generics is annoying to people who have gotten used to using them. - Brill Pappin -Original Message- From: mozvip [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:13 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket 1) Generifying* Wicket [X] Should be avoided, definitly. All this generics stuff is ruining my wicket experience. 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-t ake-on-generics-with-Wicket-tp17589984p17602298.html Sent from the Wicket - User mailing list archive at Nabble.com. - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
Clearly :) However I think the wicket developers have to be careful here as doing wrong will make a big mess :) - Brill -Original Message- From: Hoover, William [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:27 AM To: users@wicket.apache.org Subject: RE: users, please give us your opinion: what is your take on generics with Wicket Goes to show you that people have a tendency to reject things that they do not understand rather than put in the effort :o) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
+1 -Original Message- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:49 AM To: users@wicket.apache.org Subject: RE: users, please give us your opinion: what is your take on generics with Wicket I don't know, I think the discussion is going *toward* generics. Frankly I can't even see why its an issue at all, the language has evolved and uses them... Why would Wicket not also use them its inline with the current state of the language? There is no reason that people who can't get their heads around Generics can't use the older releases that don't include it, but IMO any java developer who doesn't get generics yet better make some time to learn, because like it or not, they *will* be dealing with them. - Brill Pappin -Original Message- From: Matej Knopp [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:46 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. Also If i had to decide between new WebMarkupContainerVoid and new WebMarkupContainer where the later wouldn't be generified I'd certainly go for the Void alternative. -Matej On Sun, Jun 1, 2008 at 10:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] 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. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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] - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
+1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi Elco, hi Users,
first of all thanks a lot for trying generics in wicket in the first case.
I haven't really cared about em so far, too much. So thanks a lot for
the learning experience I'm going through right now.
[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.
What currently bus me is that Components are tightly knitted together
with their class representation.
There are quite some methods that don't return the component,
but its class. Maybe most prominently 'getHomePage()' in Application.
This used to have the signature:
public abstract Class getHomePage();
And a popular implementation would be:
public Class getHomePage() {
return HomePage.class
}
So maybe in favor of that popular implementation its current signature is:
Application: public abstract Class? extends Page? getHomePage();
which is not a generic method but a method with a generified return
parameter.
But at least this works with the existing user code basis very well.
But it also implies a circle I can't break up in my mind yet.
This signature forces you to implement HomePage as a raw type, a class
without type parameters, esp. not generic.
Though on the other hand HomePage is a descendant of Component which is
generic, of course.
Which is a strong sign for HomePage to be generic too.
I think both ends don't go together well.
How is this going to be solved? Or, explained?
My tries on the signature of getHomePage() didn't really lead nowhere.
The best Try on this is:
public abstract C extends Page ClassC getHomePage();
Leaving Page and possibly Component raw.
Maybe it is enough to just generify some of Components methods?
2) How strongly do you feel about your choice above?
[x] I might rethink upgrading if my choice doesn't win.
mf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. Also If i had to decide between new WebMarkupContainerVoid and new WebMarkupContainer where the later wouldn't be generified I'd certainly go for the Void alternative. -Matej On Sun, Jun 1, 2008 at 10:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] 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. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
I don't know, I think the discussion is going *toward* generics. Frankly I can't even see why its an issue at all, the language has evolved and uses them... Why would Wicket not also use them its inline with the current state of the language? There is no reason that people who can't get their heads around Generics can't use the older releases that don't include it, but IMO any java developer who doesn't get generics yet better make some time to learn, because like it or not, they *will* be dealing with them. - Brill Pappin -Original Message- From: Matej Knopp [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:46 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. Also If i had to decide between new WebMarkupContainerVoid and new WebMarkupContainer where the later wouldn't be generified I'd certainly go for the Void alternative. -Matej On Sun, Jun 1, 2008 at 10:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] 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. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Sun, Jun 01, 2008 at 01:44:59PM -0700, Eelco Hillenius wrote: 1) Generifying* 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. 2) How strongly do you feel about your choice above? [x] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. IMHO storing a model in a Component is more a convenience than a fundamental part of component-ness. This may be part of the reason that genericizing Component is so contentious. I have many components with no model and many others, such as a TextField that uses a parent's CompoundPropertyModel, the component has a model but I really don't care about the type, since I never call getModelObject(). In all these cases (which are easily the majority in my experience), genericized Components would force me to deal with the syntactic overhead of generics with absolutely zero value. I'm all for genericizing certain components for which the model is central (e.g. ListView and Item) but I think genericizing Component is overkill, since it's relatively rare that I care about the type of a component's model. jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
I see your point... a referendum will only be as good as the current
state of the product that is being evaluated, and the expertise of those
doing the evaluation. It seems as though in this case that some of those
doing the evaluation have limited knowledge of what benefits generics
has to offer (and obviously the state of the product is incomplete- so a
released version is not what's being evaluated).
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:32 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
yes thats why i am against Referendums (politically) :)
On Mon, Jun 2, 2008 at 4:27 PM, Hoover, William [EMAIL PROTECTED]
wrote:
Goes to show you that people have a tendency to reject things that
they do not understand rather than put in the effort :o)
-Original Message-
From: richardwilko [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:21 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
ok maybe i misread this :
'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.'
but those 2 sentences seem to contradict each other, the first says
only generify IModel which I assumed ti mean that when you put a
String into a model you would get a String out of it, the second seems
to says generifiying components to make them only accept some model
types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form) {
EmailFormModel emailFormModel = (EmailFormModel)
form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any
point to using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the
listItem model object to a string.
if you have just IModel then you will have to cast.. getModelObject
will always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of
component and then return another type The problem is that this
could result in us lifting a final where we dont want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ 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.
[ x ] Whatever choice ultimately made, I'll happily convert/
start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the
listItem
model object to a string. It would also be nice if the .add() and
others methods on components could return the type of component it
is
rather than just a Component object. eg you cant do 'new
TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired
is not available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-
is -your-take-on-generics-with-Wicket-tp17589984p17601296.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---
-- To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-
yo
ur-take-on-generics-with-Wicket-tp17589984p17602507.htmlhttp://www.na
bble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-
generics-with-Wicket-tp17589984p17602507.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi Elco, hi Users,
first of all thanks a lot for trying generics in wicket in the first case.
I haven't really cared about em so far, too much. So thanks a lot for
the learning experience I'm going through right now.
[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.
As I see it generifying component far of being elegant yet.
Components are tightly knitted together with their class representation.
There are quite some methods that don't return the component,
but its class. Maybe most prominently 'getHomePage()' in Application.
This used to have the signature:
public abstract Class getHomePage();
And a popular implementation would be:
public Class getHomePage() {
return HomePage.class
}
So maybe in favor of that popular implementation its current signature is:
Application: public abstract Class? extends Page? getHomePage();
which is not a generic method but a method with a generified return
parameter.
But at least this works with the existing user code basis very well.
But it also implies a circle I can't break up in my mind yet.
This signature forces you to implement HomePage as a raw type, a class
without type parameters, esp. not generic.
Though on the other hand HomePage is a descendant of Component which is
generic, of course.
Which is a strong sign for HomePage to be generic too.
I think both ends don't go together well.
How is this going to be solved? Or, explained?
My tries on the signature of getHomePage() didn't really lead nowhere.
The best Try on this is:
public abstract C extends Page ClassC getHomePage();
Leaving Page and possibly Component raw.
Maybe it is enough to just generify some of Components methods?
2) How strongly do you feel about your choice above?
[x] I might rethink upgrading if my choice doesn't win.
mf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi, I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. @matej_k: ugh - you should count again... if I counted right, most of the responses yet prefer 'Component' /not/ being touched by generics. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. @jwcarman: There is an issue with generics on components which is leading into a big mess - and as far as I can see, many objections are especially on that topic! It might not be Wicket's fault, though, it might be a language problem (i.e. Java's to blame). But IMHO putting generics on Component is a bad design, since it per se touches all of Wicket's Components without urgent need. Boilerplate over and over. If I look at my components and libraries (and yes, i have tried out 1.4!) - I have at most 30% of my components containing a Model! Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 11:22 AM, Jan Kriesten [EMAIL PROTECTED] wrote: @jwcarman: There is an issue with generics on components which is leading into a big mess - and as far as I can see, many objections are especially on that topic! It might not be Wicket's fault, though, it might be a language problem (i.e. Java's to blame). How about if we clearly document specific code snippets on the wiki that are causing troubles with people? Then, we evaluate how/if we can address the issue. If there are a lot of issues left on the wiki page that the resolution is Java generics suck and we can't code around this, then perhaps we decide at that point that generics are in fact not worth the troubles. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Ahhh... there's a good starting point for the gotchas... I agree. It is not a big issue to use Void when needed. I doubt anyone would be using something like Class? extends Page? extends IModelT unless they themselves are attempting to extend a generic component that they want to extend its generic capabilities. Anyone that doesn't want to use the complete generic signature does not have to (MyPage extends PageSomeModel and Class? extends MyPage or ClassMyPage). That's the nice thing... It's up to the user. -Original Message- From: Scott Swank [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:11 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Agreed. I don't see a problem with having to type LinkVoid or PageVoid instead of Link/Page. That's simply the way that generics are implemented in Java. Are there places in the API where an end user would have to type something like Class? extends Page? extends IModelT? That way madness lies, however I haven't seen anything like that in 1.4M1 (I'll let you know about M2 later today). So unless I'm missing something pretty beafy, which I don't see here: http://cwiki.apache.org/WICKET/generics.html I just don't see the problem with the current direction. Cheers, Scott On Mon, Jun 2, 2008 at 8:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
Sounds like a good idea... Are you going to create it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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] - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi, But IMHO putting generics on Component is a bad design, since it per se touches all of Wicket's Components without urgent need. I *really* would like to see a clarification of this statement. In Wicket the component and model are very tightly coupled. What is a *good design* alternative, where only IModel is generified? getModelObject() returns Object? getModel returns IModel?? Regards, Sebastiaan Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 5:22 PM, Jan Kriesten [EMAIL PROTECTED] wrote: Hi, I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. @matej_k: ugh - you should count again... if I counted right, most of the responses yet prefer 'Component' /not/ being touched by generics. Question is, how many of those users actually use generified wicket on day-to-day basis. -Matej +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. @jwcarman: There is an issue with generics on components which is leading into a big mess - and as far as I can see, many objections are especially on that topic! It might not be Wicket's fault, though, it might be a language problem (i.e. Java's to blame). But IMHO putting generics on Component is a bad design, since it per se touches all of Wicket's Components without urgent need. Boilerplate over and over. If I look at my components and libraries (and yes, i have tried out 1.4!) - I have at most 30% of my components containing a Model! Best regards, --- Jan. - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
I'm adding a Gotchas section now. On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William [EMAIL PROTECTED] wrote: Sounds like a good idea... Are you going to create it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi Matej, Question is, how many of those users actually use generified wicket on day-to-day basis. well, I did, and it really doesn't looked nice (and it doesn't work as it should in the end, but that's another story). The main point is (repeatedly) ignored by the people who are 'pro' generics: Why do you have to put generics on Components, when need is only in a fraction of cases? Discussing the possibility of Void is somewhat an obscure workaround. It's just boilerplate in more than 70% (of my cases), and this boilerplate gets repeated over and over again with each assignment. Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Agreed. I don't see a problem with having to type LinkVoid or PageVoid instead of Link/Page. That's simply the way that generics are implemented in Java. Are there places in the API where an end user would have to type something like Class? extends Page? extends IModelT? That way madness lies, however I haven't seen anything like that in 1.4M1 (I'll let you know about M2 later today). So unless I'm missing something pretty beafy, which I don't see here: http://cwiki.apache.org/WICKET/generics.html I just don't see the problem with the current direction. Cheers, Scott On Mon, Jun 2, 2008 at 8:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Good question... I would add to that and say: how many of those users actually use generified wicket on day-to-day basis? how many of those users actually implement generics on day-to-day basis (not just using them- like ListMyClass)? -Original Message- From: Matej Knopp [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:28 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 5:22 PM, Jan Kriesten [EMAIL PROTECTED] wrote: Hi, I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. @matej_k: ugh - you should count again... if I counted right, most of the responses yet prefer 'Component' /not/ being touched by generics. Question is, how many of those users actually use generified wicket on day-to-day basis. -Matej +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. @jwcarman: There is an issue with generics on components which is leading into a big mess - and as far as I can see, many objections are especially on that topic! It might not be Wicket's fault, though, it might be a language problem (i.e. Java's to blame). But IMHO putting generics on Component is a bad design, since it per se touches all of Wicket's Components without urgent need. Boilerplate over and over. If I look at my components and libraries (and yes, i have tried out 1.4!) - I have at most 30% of my components containing a Model! Best regards, --- Jan. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi Sebastiaan, I *really* would like to see a clarification of this statement. In Wicket the component and model are very tightly coupled. that's part of the problem, agreed. What is a *good design* alternative, where only IModel is generified? getModelObject() returns Object? getModel returns IModel?? IMHO the practical solution would be to leave generics from components and have getModelObject return Object, yes. On certain components (ListView e.g.), those methods may be overridden by more concrete implementations. Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Can you elaborate? What (anti)pattern(s) make you think that generics in the components are bad design? Besides the effort involved for the wicket developers, as a user I was leaning the opposite way... But maybe I missed something (not unusual). - Brill Pappin -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:23 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Hi, I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. @matej_k: ugh - you should count again... if I counted right, most of the responses yet prefer 'Component' /not/ being touched by generics. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. @jwcarman: There is an issue with generics on components which is leading into a big mess - and as far as I can see, many objections are especially on that topic! It might not be Wicket's fault, though, it might be a language problem (i.e. Java's to blame). But IMHO putting generics on Component is a bad design, since it per se touches all of Wicket's Components without urgent need. Boilerplate over and over. If I look at my components and libraries (and yes, i have tried out 1.4!) - I have at most 30% of my components containing a Model! Best regards, --- Jan. - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
If you use more than one type of model for a given component I would hardly say that it is only a fraction of the time. Do you use only one type of model on all your components? :o) The use of Void is not an obscure workaround. Why do you think they have it? I think it's intent is very clear if you understand what void represents. The key point is that Java generics are not runtime generics ;o) -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:37 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Hi Matej, Question is, how many of those users actually use generified wicket on day-to-day basis. well, I did, and it really doesn't looked nice (and it doesn't work as it should in the end, but that's another story). The main point is (repeatedly) ignored by the people who are 'pro' generics: Why do you have to put generics on Components, when need is only in a fraction of cases? Discussing the possibility of Void is somewhat an obscure workaround. It's just boilerplate in more than 70% (of my cases), and this boilerplate gets repeated over and over again with each assignment. Best regards, --- Jan. - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
James Carman wrote: I'm adding a Gotchas section now. Your pallete gotcha seems more like a JIRA to me. :-) It's not really about generics in general, but about a specific choice in 1 component (which really seems incorrect to me, i.e., PECS). One of the gotcha's I think is the getHomePage() signature... public abstract Class? extends Page? getHomePage(); This breaks raw types (you can't return raw home page). I don't see any way out of this one without making the getHomePage() signature incorrect (i.e., you can't make it a generic method, which was used to solve the problem where a method argument had the type Class? extends Page?). Regards, Sebastiaan On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William [EMAIL PROTECTED] wrote: Sounds like a good idea... Are you going to create it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: users, please give us your opinion: what is your take on generics with Wicket
A raw type is a parameterized type in which the type parameters are not filled in, i.e., new HashMap() (instead of new HashMapString, Integer()). Just try to return one of your old (non-generified) HomePage.class classes (i.e., HomePage extends WebPage instead of HomePage extends WebPageVoid) in your WebApplication's getHomePage() method, and you will see that it does not compile. Regards, Sebastiaan Brill Pappin wrote: I'm likely missing something here, but why would you want to return something other than a *Page object? Wouldn't that cause some issues with the application? Maybe I don't understand what you mean by raw type. - Brill Pappin -Original Message- From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:53 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket James Carman wrote: I'm adding a Gotchas section now. Your pallete gotcha seems more like a JIRA to me. :-) It's not really about generics in general, but about a specific choice in 1 component (which really seems incorrect to me, i.e., PECS). One of the gotcha's I think is the getHomePage() signature... public abstract Class? extends Page? getHomePage(); This breaks raw types (you can't return raw home page). I don't see any way out of this one without making the getHomePage() signature incorrect (i.e., you can't make it a generic method, which was used to solve the problem where a method argument had the type Class? extends Page?). Regards, Sebastiaan On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William [EMAIL PROTECTED] wrote: Sounds like a good idea... Are you going to create it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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] - 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] - 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] smime.p7s Description: S/MIME Cryptographic Signature
Re: users, please give us your opinion: what is your take on generics with Wicket
Yes, the trick here is to not muddy up Wicket for the newcomers. Wicket needs to be easy to learn and understand in order for it to be adopted by the masses! On Mon, Jun 2, 2008 at 11:46 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: Question is, how many of those users are core committers. Not everybody is a generics wizz you know, nor has the need to become one. Most users want to just build web apps in a clean, self-documenting API that doesn't put too much burden upon them - conceptually and number of characters to type, read and understand. Martijn On Mon, Jun 2, 2008 at 5:28 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Jun 2, 2008 at 5:22 PM, Jan Kriesten [EMAIL PROTECTED] wrote: Hi, I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. @matej_k: ugh - you should count again... if I counted right, most of the responses yet prefer 'Component' /not/ being touched by generics. Question is, how many of those users actually use generified wicket on day-to-day basis. -Matej +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. @jwcarman: There is an issue with generics on components which is leading into a big mess - and as far as I can see, many objections are especially on that topic! It might not be Wicket's fault, though, it might be a language problem (i.e. Java's to blame). But IMHO putting generics on Component is a bad design, since it per se touches all of Wicket's Components without urgent need. Boilerplate over and over. If I look at my components and libraries (and yes, i have tried out 1.4!) - I have at most 30% of my components containing a Model! Best regards, --- Jan. - 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] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi Sebastian, What about getModel()? If componennt is not generified I'm really wondering if the there is any benefit to generics at all... (I do really think it will spawn lots of questions on the list as well). what's the problem with getModel? If you specialize on a certain Component, you can implement T getModel() ? Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Why can't this be done the way the java API does it, and allow people to use it or not as they want? Wicket is pretty clean in terms of the API, and there are interfaces for most things... So what's the problem with adding the generics to the interfaces? AFAIK this would allow them to be ignored if the user didn't have a place for them. - Brill Pappin -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:46 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Hi Sebastiaan, I *really* would like to see a clarification of this statement. In Wicket the component and model are very tightly coupled. that's part of the problem, agreed. What is a *good design* alternative, where only IModel is generified? getModelObject() returns Object? getModel returns IModel?? IMHO the practical solution would be to leave generics from components and have getModelObject return Object, yes. On certain components (ListView e.g.), those methods may be overridden by more concrete implementations. Regards, --- Jan. - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi William, If you use more than one type of model for a given component I would hardly say that it is only a fraction of the time. Do you use only one type of model on all your components? :o) read again - I said 70% of my components don't have a Model... The use of Void is not an obscure workaround. Why do you think they have it? I think it's intent is very clear if you understand what void represents. The key point is that Java generics are not runtime generics ;o) See above, the point is having Void in there for especially nothing to gain - Just make reading harder and each assignment even longer... Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Brill Pappin wrote: Why can't this be done the way the java API does it, and allow people to use it or not as they want? Wicket is pretty clean in terms of the API, and there are interfaces for most things... So what's the problem with adding the generics to the interfaces? AFAIK this would allow them to be ignored if the user didn't have a place for them. Well for one, getHomePage() does not compile if you returned home page is not generified, so it's not really that simple (opt in vs opt out). Regards, Sebastiaan - Brill Pappin -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:46 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Hi Sebastiaan, I *really* would like to see a clarification of this statement. In Wicket the component and model are very tightly coupled. that's part of the problem, agreed. What is a *good design* alternative, where only IModel is generified? getModelObject() returns Object? getModel returns IModel?? IMHO the practical solution would be to leave generics from components and have getModelObject return Object, yes. On certain components (ListView e.g.), those methods may be overridden by more concrete implementations. Regards, --- Jan. - 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] smime.p7s Description: S/MIME Cryptographic Signature
RE: users, please give us your opinion: what is your take on generics with Wicket
I'm likely missing something here, but why would you want to return something other than a *Page object? Wouldn't that cause some issues with the application? Maybe I don't understand what you mean by raw type. - Brill Pappin -Original Message- From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:53 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket James Carman wrote: I'm adding a Gotchas section now. Your pallete gotcha seems more like a JIRA to me. :-) It's not really about generics in general, but about a specific choice in 1 component (which really seems incorrect to me, i.e., PECS). One of the gotcha's I think is the getHomePage() signature... public abstract Class? extends Page? getHomePage(); This breaks raw types (you can't return raw home page). I don't see any way out of this one without making the getHomePage() signature incorrect (i.e., you can't make it a generic method, which was used to solve the problem where a method argument had the type Class? extends Page?). Regards, Sebastiaan On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William [EMAIL PROTECTED] wrote: Sounds like a good idea... Are you going to create it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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] - 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] - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
Lets not forget the stats we're all aware of (or should be) that 80% of resources in software development are in maintenance... If I'm looking at my ROI, then my developers can type a few extra words in order to reduce that resource load. And lets face it; it *all* comes down to maintenance (and the cost of), despite effort on the initial development. One thing that means for me, is generics... Just like TDD, it reduces the issue count (among other things). - Brill Pappin -Original Message- From: Martijn Dashorst [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:47 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Question is, how many of those users are core committers. Not everybody is a generics wizz you know, nor has the need to become one. Most users want to just build web apps in a clean, self-documenting API that doesn't put too much burden upon them - conceptually and number of characters to type, read and understand. Martijn On Mon, Jun 2, 2008 at 5:28 PM, Matej Knopp [EMAIL PROTECTED] wrote: On Mon, Jun 2, 2008 at 5:22 PM, Jan Kriesten [EMAIL PROTECTED] wrote: Hi, I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. @matej_k: ugh - you should count again... if I counted right, most of the responses yet prefer 'Component' /not/ being touched by generics. Question is, how many of those users actually use generified wicket on day-to-day basis. -Matej +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. @jwcarman: There is an issue with generics on components which is leading into a big mess - and as far as I can see, many objections are especially on that topic! It might not be Wicket's fault, though, it might be a language problem (i.e. Java's to blame). But IMHO putting generics on Component is a bad design, since it per se touches all of Wicket's Components without urgent need. Boilerplate over and over. If I look at my components and libraries (and yes, i have tried out 1.4!) - I have at most 30% of my components containing a Model! Best regards, --- Jan. - 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] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 11:52 AM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: James Carman wrote: I'm adding a Gotchas section now. Your pallete gotcha seems more like a JIRA to me. :-) It's not really about generics in general, but about a specific choice in 1 component (which really seems incorrect to me, i.e., PECS). One of the gotcha's I think is the getHomePage() signature... public abstract Class? extends Page? getHomePage(); This breaks raw types (you can't return raw home page). I don't see any way out of this one without making the getHomePage() signature incorrect (i.e., you can't make it a generic method, which was used to solve the problem where a method argument had the type Class? extends Page?). So, add that to the wiki so that we can discuss it. Regards, Sebastiaan On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William [EMAIL PROTECTED] wrote: Sounds like a good idea... Are you going to create it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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] - 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] - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
I read it, but I think most people will be using models more frequently than 30% of the time. Personally, I use them 99% of the time. -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:54 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Hi William, If you use more than one type of model for a given component I would hardly say that it is only a fraction of the time. Do you use only one type of model on all your components? :o) read again - I said 70% of my components don't have a Model... The use of Void is not an obscure workaround. Why do you think they have it? I think it's intent is very clear if you understand what void represents. The key point is that Java generics are not runtime generics ;o) See above, the point is having Void in there for especially nothing to gain - Just make reading harder and each assignment even longer... Regards, --- Jan. - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
+1 Even if its one of the built in composite models, you still kind of need them for most things you do. - Brill -Original Message- From: Hoover, William [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:59 AM To: users@wicket.apache.org Subject: RE: users, please give us your opinion: what is your take on generics with Wicket I read it, but I think most people will be using models more frequently than 30% of the time. Personally, I use them 99% of the time. -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:54 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Hi William, If you use more than one type of model for a given component I would hardly say that it is only a fraction of the time. Do you use only one type of model on all your components? :o) read again - I said 70% of my components don't have a Model... The use of Void is not an obscure workaround. Why do you think they have it? I think it's intent is very clear if you understand what void represents. The key point is that Java generics are not runtime generics ;o) See above, the point is having Void in there for especially nothing to gain - Just make reading harder and each assignment even longer... Regards, --- Jan. - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Sun, Jun 1, 2008 at 9:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: 1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [half-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. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) I see the stronger-typing made possible with Generics as a step forward for Java and for Wicket. I believe that Generics will improve my code, and make my life easier. I understand that actually implementing the Generified objects is harder than using them, and that this task rests mostly on the devs' shoulders! 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Whatever the devs decide, I'm not going to stop using Wicket (or refuse to upgrade forever more) just because they've not implemented something exactly the way I personally prefer! I have faith that, with discussion, the right decision will be made for the framework as a whole. After all, if I weren't happy to go along with the majority view, I'd have to write everything myself... Charlie. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 3:54 PM, Martin Funk [EMAIL PROTECTED]
wrote:
There are quite some methods that don't return the component,
but its class. Maybe most prominently 'getHomePage()' in Application.
This used to have the signature:
public abstract Class getHomePage();
And a popular implementation would be:
public Class getHomePage() {
return HomePage.class
}
So maybe in favor of that popular implementation its current signature is:
Application: public abstract Class? extends Page? getHomePage();
which is not a generic method but a method with a generified return
parameter.
But at least this works with the existing user code basis very well.
But it also implies a circle I can't break up in my mind yet.
This signature forces you to implement HomePage as a raw type, a class
without type parameters, esp. not generic.
Though on the other hand HomePage is a descendant of Component which is
generic, of course.
Which is a strong sign for HomePage to be generic too.
I think both ends don't go together well.
How is this going to be solved? Or, explained?
shrug
One could generify Application. ;-)
class ApplicationP extends Page {
public abstract P getHomePage();
}
Generifying Component buys you no casting, at the expense of being hideously
verbose at times.
Generifying IModel buys you more obvious method signatures, particularly for
things like DropDownChoice.
The second is almost certainly worth doing. That said, I use PropertyModel
more often than anything else, and that doesn't allow you to make any
guarantees anyway. :-/
Al
Re: users, please give us your opinion: what is your take on generics with Wicket
Yes, property model (and compound friends) don't mix well with generics. With generics a type safe alternative is wanted (and a very good start is Matej and Johan's type-safe model implementation). Regards, Sebastiaan Jan Kriesten wrote: hi al, The second is almost certainly worth doing. That said, I use PropertyModel more often than anything else, and that doesn't allow you to make any guarantees anyway. :-/ good point. :-) regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: users, please give us your opinion: what is your take on generics with Wicket
hi william, Wouldn't that infer that the component has to have generics, or am I missing something here? you miss something... getModel/getModelObject would have to be non-final and overriden by the specialized component (return types are covariant, so you can override object with something more specific). regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Enlighten me with an example -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 12:23 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket hi william, Wouldn't that infer that the component has to have generics, or am I missing something here? you miss something... getModel/getModelObject would have to be non-final and overriden by the specialized component (return types are covariant, so you can override object with something more specific). regards, --- jan. - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
You really have to use it to appreciate the benefits. Quick glance will just be scary :) -Matej On Mon, Jun 2, 2008 at 6:45 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Question is, how many of those users actually use generified wicket on day-to-day basis. Common, a quick glance and comparing some of the code/ examples you see with the code you write now (with 1.2/ 1.3) is enough to get a good - and as far as I am concerned informed well enough - idea. Eelco - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
Then we are on the same page with one thing... some level in the
component hierarchy would have to be generic.
Your original example specified T getModel() - you must have meant T
getModelObject() ;o)
-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 12:34 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
hi william,
Enlighten me with an example
just like that:
Component { public object getModelObject(){ ... } } FormComponentT
extends Component { public T getModelObject() { ... } }
regards, --- jan.
-
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]
Re: users, please give us your opinion: what is your take on generics with Wicket
IMHO storing a model in a Component is more a convenience than a fundamental part of component-ness. This may be part of the reason that genericizing Component is so contentious. I agree. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
hi william,
Enlighten me with an example
just like that:
Component { public object getModelObject(){ ... } }
FormComponentT extends Component { public T getModelObject() { ... } }
regards, --- jan.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 12:11 PM, Sebastiaan van Erk [EMAIL PROTECTED] wrote: A raw type is a parameterized type in which the type parameters are not filled in, i.e., new HashMap() (instead of new HashMapString, Integer()). Just try to return one of your old (non-generified) HomePage.class classes (i.e., HomePage extends WebPage instead of HomePage extends WebPageVoid) in your WebApplication's getHomePage() method, and you will see that it does not compile. There is a section on the wiki addressing this now. I would propose that whenever referring to class objects that represent Page subclasses we use Class? extends Page rather than Class? extends Page?. This allows us to specify that it has to be a page class, but it doesn't make the page class have to be generified. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
You could use Java's covariant return types to override getModel() to
return a specific type. Which would mean that you would need to subclass
to simulate generics (with a new subclass for each type). Also, when
using anonymous subclasses it becomes rather pointless and you'd be back
to casting.
Regards,
Sebastiaan
Hoover, William wrote:
Wouldn't that infer that the component has to have generics, or am I
missing something here?
Something like...
public abstract class ComponentM extends IModelT, T implements
IClusterable, IConverterLocator {
...
public final M getModel(){
...
}
...
public final T getModelObject(){
...
}
...
}
-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 12:03 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
Hi Sebastian,
What about getModel()? If componennt is not generified I'm really
wondering if the there is any benefit to generics at all... (I do
really think it will spawn lots of questions on the list as well).
what's the problem with getModel? If you specialize on a certain
Component, you can implement T getModel() ?
Regards, --- Jan.
-
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]
smime.p7s
Description: S/MIME Cryptographic Signature
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 7:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. I just want to get a hunch of what people are thinking at the moment. It's not meant to be a discussion thread, nor a decision thread. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
hi sebastiaan, You could use Java's covariant return types to override getModel() to return a specific type. Which would mean that you would need to subclass to simulate generics (with a new subclass for each type). not really, you can do generify your components from a certain level and wouldn't have to subclass for each type. that way you could require formcomponents to have generics on them, without the whole component tree generified. but i guess this would also lead to many questions why this and not that... i'd prefer living with have to cast when it comes to getModel/getModelObject... regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Eelco Hillenius [EMAIL PROTECTED] wrote:1) Generifying* Wicket [X] They, the core developers, knows better then me (everyday users doesn't have in-depth and extensive view on generification pro and cons. As usual, to find a good compromise may be _very_ tricky business). 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. Stefan Jozsa
RE: users, please give us your opinion: what is your take on generics with Wicket
Wouldn't that infer that the component has to have generics, or am I
missing something here?
Something like...
public abstract class ComponentM extends IModelT, T implements
IClusterable, IConverterLocator {
...
public final M getModel(){
...
}
...
public final T getModelObject(){
...
}
...
}
-Original Message-
From: Jan Kriesten [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 12:03 PM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
Hi Sebastian,
What about getModel()? If componennt is not generified I'm really
wondering if the there is any benefit to generics at all... (I do
really think it will spawn lots of questions on the list as well).
what's the problem with getModel? If you specialize on a certain
Component, you can implement T getModel() ?
Regards, --- Jan.
-
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]
Re: users, please give us your opinion: what is your take on generics with Wicket
Question is, how many of those users actually use generified wicket on day-to-day basis. Common, a quick glance and comparing some of the code/ examples you see with the code you write now (with 1.2/ 1.3) is enough to get a good - and as far as I am concerned informed well enough - idea. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
hi al, The second is almost certainly worth doing. That said, I use PropertyModel more often than anything else, and that doesn't allow you to make any guarantees anyway. :-/ good point. :-) regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William wrote: I read it, but I think most people will be using models more frequently than 30% of the time. Personally, I use them 99% of the time. Really? Haven't you heard of CompoundPropertyModel? jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
I am currently using 1.4 M1 and here are my choices: 1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. _ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi all, [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. [X] I might rethink upgrading if my choice doesn't win. I didn't try wicket 1.4 yet, but I read questions and comments from users in this list. My impression so far has been that there has been a small design mistake in the way the current 1.4 implementation has been done. I perceive that IModelT is conceptually correct as a Model can be seen as a container of something (of type T). Writing DropDownChoiceT is a shortcut that does not seem conceptually correct as in this case, the component is not a container of type T but a container of type IModelT. So you should have something like DropDownChoiceIModelT (I know this not valid java). Generifying the Page component is even worse as possibly a page can hold components with different model types and not have a model type on its own. Also, wicket is designed to allow some components not to have model on their own and rely on the model stored in a parent component (very nice and powerful feature). Please note that using generic this way is already possible with wicket 1.3 if you define an interface that would be for instance IMyModelT extends IModel. For instance, I have a generic model defined as DetachableBeanModelK,T where K is the key type and T is the bean type. This type is indeed a container of a key element and of a bean element. I hope it helps, Bernard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
I think you miss John's point, which is that when you use a CompoundPropertyModel for a component, all its children typically do not reference models explicitly. Thus you typically use an explicit model on 30% of your components if you have a form-heavy web-app; the other components use the implicit model provided by the parent's CompoundPropertyModel. Regards, Al On Mon, Jun 2, 2008 at 6:42 PM, Hoover, William [EMAIL PROTECTED] wrote: Wow, last time I checked CompoundPropertyModel is a model ;o) -Original Message- From: John Krasnay [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 1:22 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William wrote: I read it, but I think most people will be using models more frequently than 30% of the time. Personally, I use them 99% of the time. Really? Haven't you heard of CompoundPropertyModel? jk - 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]
RE: users, please give us your opinion: what is your take on generics with Wicket
Wow, last time I checked CompoundPropertyModel is a model ;o) -Original Message- From: John Krasnay [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 1:22 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William wrote: I read it, but I think most people will be using models more frequently than 30% of the time. Personally, I use them 99% of the time. Really? Haven't you heard of CompoundPropertyModel? jk - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hello everyone, I feel bad that a vote thread has been converted to one of discussion... At this moment wicket is *for *creating custom components. If these custom component writing gets complicated we will not be able to appreciate wicket as much(as much as we do now).Generics will complicate the *extend* at the moment for new user...I feel(after reading through everything). In core-java , fewer classes aim for extension by user. They rather are end product to be used, to be composed of. The best way still for wicket is *to implement generics partially *and* then start incorporating into OUT-OF-BOX(components less prone to extension) later on in further releases. The fact is that less people can make to wicket core-development team, and then who will maintain the bloat(meaning undesired syntactical features). Who will release non-generics versions for freshers. In Design Patterns I learnt about the open-closed principle. Closed for change and open for extension. Generics forces us to see into a new design pattern---Generify the the most closed only, based on use cases--If there is more of a need of extension of classes by end user AND there is flexibility while extending(wicket is one case which is flexible when you extend)--then wait, do not generify. * On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset [EMAIL PROTECTED] wrote: Hi all, [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. [X] I might rethink upgrading if my choice doesn't win. I didn't try wicket 1.4 yet, but I read questions and comments from users in this list. My impression so far has been that there has been a small design mistake in the way the current 1.4 implementation has been done. I perceive that IModelT is conceptually correct as a Model can be seen as a container of something (of type T). Writing DropDownChoiceT is a shortcut that does not seem conceptually correct as in this case, the component is not a container of type T but a container of type IModelT. So you should have something like DropDownChoiceIModelT (I know this not valid java). Generifying the Page component is even worse as possibly a page can hold components with different model types and not have a model type on its own. Also, wicket is designed to allow some components not to have model on their own and rely on the model stored in a parent component (very nice and powerful feature). Please note that using generic this way is already possible with wicket 1.3 if you define an interface that would be for instance IMyModelT extends IModel. For instance, I have a generic model defined as DetachableBeanModelK,T where K is the key type and T is the bean type. This type is indeed a container of a key element and of a bean element. I hope it helps, Bernard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
I got the point, but I take things as people state them. It was stated that 70% of the time models are not being used (such is the case for LinkVoid). As you stated, they are being used indirectly. That is different. If that is the case then I agree that the percentage of components using model indirectly would be reduced for form-heavy applications (as you stated). On the contrary, a lot of applications are not form-heavy (i.e. Ajax heavy apps, etc.) which also need to be accounted for in the figures. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Al Maw Sent: Monday, June 02, 2008 2:09 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket I think you miss John's point, which is that when you use a CompoundPropertyModel for a component, all its children typically do not reference models explicitly. Thus you typically use an explicit model on 30% of your components if you have a form-heavy web-app; the other components use the implicit model provided by the parent's CompoundPropertyModel. Regards, Al On Mon, Jun 2, 2008 at 6:42 PM, Hoover, William [EMAIL PROTECTED] wrote: Wow, last time I checked CompoundPropertyModel is a model ;o) -Original Message- From: John Krasnay [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 1:22 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 02, 2008 at 11:59:09AM -0400, Hoover, William wrote: I read it, but I think most people will be using models more frequently than 30% of the time. Personally, I use them 99% of the time. Really? Haven't you heard of CompoundPropertyModel? jk - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi Atul, Please read again the initial post from Eelco. He explicitly wrote: Note that it is not a vote; we only want to get an idea of what you think. and further away: Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions!. Bernard. atul singh a écrit : Hello everyone, I feel bad that a vote thread has been converted to one of discussion... At this moment wicket is *for *creating custom components. If these custom component writing gets complicated we will not be able to appreciate wicket as much(as much as we do now).Generics will complicate the *extend* at the moment for new user...I feel(after reading through everything). In core-java , fewer classes aim for extension by user. They rather are end product to be used, to be composed of. The best way still for wicket is *to implement generics partially *and* then start incorporating into OUT-OF-BOX(components less prone to extension) later on in further releases. The fact is that less people can make to wicket core-development team, and then who will maintain the bloat(meaning undesired syntactical features). Who will release non-generics versions for freshers. In Design Patterns I learnt about the open-closed principle. Closed for change and open for extension. Generics forces us to see into a new design pattern---Generify the the most closed only, based on use cases--If there is more of a need of extension of classes by end user AND there is flexibility while extending(wicket is one case which is flexible when you extend)--then wait, do not generify. * On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset [EMAIL PROTECTED] wrote: Hi all, [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. [X] I might rethink upgrading if my choice doesn't win. I didn't try wicket 1.4 yet, but I read questions and comments from users in this list. My impression so far has been that there has been a small design mistake in the way the current 1.4 implementation has been done. I perceive that IModelT is conceptually correct as a Model can be seen as a container of something (of type T). Writing DropDownChoiceT is a shortcut that does not seem conceptually correct as in this case, the component is not a container of type T but a container of type IModelT. So you should have something like DropDownChoiceIModelT (I know this not valid java). Generifying the Page component is even worse as possibly a page can hold components with different model types and not have a model type on its own. Also, wicket is designed to allow some components not to have model on their own and rely on the model stored in a parent component (very nice and powerful feature). Please note that using generic this way is already possible with wicket 1.3 if you define an interface that would be for instance IMyModelT extends IModel. For instance, I have a generic model defined as DetachableBeanModelK,T where K is the key type and T is the bean type. This type is indeed a container of a key element and of a bean element. I hope it helps, Bernard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 02, 2008 at 03:05:46PM -0400, Hoover, William wrote: I got the point, but I take things as people state them. It was stated that 70% of the time models are not being used (such is the case for LinkVoid). As you stated, they are being used indirectly. That is different. If that is the case then I agree that the percentage of components using model indirectly would be reduced for form-heavy applications (as you stated). On the contrary, a lot of applications are not form-heavy (i.e. Ajax heavy apps, etc.) which also need to be accounted for in the figures. I would contend that the important thing to look at is not the percentage of component instances that use models, but the percent for which your code explicitly calls getModel() or getModelObject(). If you're not calling one of these methods, you have received no value for typing the generic syntax. I would be surprised if I explicitly call one of these methods on more than about 20% of my Wicket component instances. So for me, it's not the verbosity of generics that is the problem. When the syntax is helping you avoid a cast somewhere else, it's worth it. What bothers me is that 80% of time (for me, anyway) it doesn't save me a cast, it just makes for more typing and less readable code. (Also, please keep in mind I'm referring to genericizing Component. Like most on this thread I'm a big fan of genericizing IModel.) jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
My vote: X - Can best be done like currently in the 1.4 branch, where models and components are both generified X - Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. I have to modify that last sentence, though - because I will continue using Wicket, because it's the best. But I have already upgraded all of my applications to use 1.4, and there wouldn't be any happily about it to back it out and stop using generics for me. They are too valuable to lose. I have been using 1.4 with generics since before M1 was released, with nearly half a dozen deployed production applications now running on either 1.4-M1 or M2. Without intending to offend anyone, the rest of my thoughts on this: I've read over 100 emails on this thread, and nearly all of the ones against keeping generics like they are currently implemented are from people who do not fully understand them and have not used them on a day-to-day basis. I'll grant you that the first switch to 1.4 was a little intimidating, but I had been wishing for generics in IModel since early 1.2 releases (fortunately I never switched to 2.0). Once you use them regularly, you will grow to appreciate them. I also agree that there are still some method signatures that may be done better - we'll put those on the wiki as we come across them. Some are saying we don't need to generify component - but then you can't call getModelObject() and get the right type - so generics didn't help you within your component. Where else will a generified model help you? Where are you using it that's not in a component? Some say we should not generify component, but they want getModelObject() to return the right type - they don't understand generics. There's a large discussion that says I don't use models in my components - interesting, because nearly all of the framework components use models - nearly all of my components use models - a model is a pretty core part of a component - it's what stores the data that the component is rendering or modifying - you can't tell the rest of us that we shouldn't have a generic component because it wouldn't be used 70% of the time - that's only your use case. When we talk about new users being intimidated by Wicket because of generics, it makes me think of the blog post by Martijn on Jonathan's statement don't hire wicket programmers [1] - a good programmer with a solid understanding of generics will not be intimidated when they start using this framework. This in no way implies that if you do not currently like the generics that you are a bad programmer. It only means that generics are still new to some, they have not used them enough yet to be really comfortable with them. They are very valuable, but yes, java could've implemented them better. So, we'd all better get good with generics - they've been in java for quite a while now, and they're here to stay. No reason Wicket shouldn't / can't do the same! Jeremy Thomerson 1 - http://martijndashorst.com/blog/2008/03/30/dont-hire-wicket-programmers/ On Sun, Jun 1, 2008 at 3:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] 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. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - To
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi Sebastiann, just for clarifying my understanding of the vocabulary: A_HomePage extends WebPage and B_HomePage extends WebPageVoid are both non-generified java classes. It is just that A_HomePage extends the raw type of the generic type WebPageT whereas B_HomePage extends the parameterized type, with type parameter 'Void' of the generic type WebPageT So if I get it right it is not the generification of the HomePage, that makes the difference but its weather it is derived of a parameterized type. Esp. if the signature of 'public abstract Class? extends Page? getHomePage();' stays that way the HomePage can't be generified. Can someone pleas elaborate on this? mf 2008/6/2 Sebastiaan van Erk [EMAIL PROTECTED]: A raw type is a parameterized type in which the type parameters are not filled in, i.e., new HashMap() (instead of new HashMapString, Integer()). Just try to return one of your old (non-generified) HomePage.class classes (i.e., HomePage extends WebPage instead of HomePage extends WebPageVoid) in your WebApplication's getHomePage() method, and you will see that it does not compile. Regards, Sebastiaan Brill Pappin wrote: I'm likely missing something here, but why would you want to return something other than a *Page object? Wouldn't that cause some issues with the application? Maybe I don't understand what you mean by raw type. - Brill Pappin -Original Message- From: Sebastiaan van Erk [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:53 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket James Carman wrote: I'm adding a Gotchas section now. Your pallete gotcha seems more like a JIRA to me. :-) It's not really about generics in general, but about a specific choice in 1 component (which really seems incorrect to me, i.e., PECS). One of the gotcha's I think is the getHomePage() signature... public abstract Class? extends Page? getHomePage(); This breaks raw types (you can't return raw home page). I don't see any way out of this one without making the getHomePage() signature incorrect (i.e., you can't make it a generic method, which was used to solve the problem where a method argument had the type Class? extends Page?). Regards, Sebastiaan On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William [EMAIL PROTECTED] wrote: Sounds like a good idea... Are you going to create it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of James Carman Sent: Monday, June 02, 2008 11:06 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To
Re: users, please give us your opinion: what is your take on generics with Wicket
after using 1.4 full time i am more and more coming around to this
point of view also.
disclaimer: terms like vast majority are based on my own coding experience...
the fact is, it doesnt matter how often you use models in components,
its how often you actually have to cast the model object to a type, eg
when you call getmodelobject() or getmodel() on the component. a big
percentage of the time you bind the model to a property - like in form
components, or push in a model once and never access it again - like
in dropdownchoice choices model, generics offer you no benefit in
these two cases.
here are a couple of thoughts i have:
generics for formcomponents do not make sense, most of the time they
can figure out the type by inspecting their model. further, generics
did not get rid of the need to specify the type as a constructor
argument: new TextFieldInteger(num, Integer.class)
a lot of times there is no clear type, eg Label. should that be
LabelString? why do i need to repeat the type twice? new
LabelString(username, new PropertyModelString(this,
username)); it is very redundant for some components. new
Label(username, new ProeprtyModelString(this, usenrame)) is just
as self documenting.
a vast majority of components are set it and forget it: add(new
TextField(foo, new PropertyModelString(this, username));
developer doesnt keep a reference to these components, so generics are
just noise, the type of the model is enough.
i think the fact remains that component's default model is just there
for user's convenience. it would really suck to have to write an
ondetach() handler every time, especially since a single model
instance per component covers 90% usecase. if java had something like
scala's traits, model would not be part of Component.
i am willing to drop component model support if the following can be met:
certain constructors stay generified to document certain aspects, eg
dropdownchoice constructor should be generified.
support generification of certain components, even if it means
removing final from certain methods. this code should still be
possible:
add(new ListViewPerson(people) { protected void
onPopulate(ItemPerson person) { where getModel() of that item
returns IModelPerson
for me, the driving point is that i havent enjoyed writing wicket code
against 1.4 trunk as much.
-igor
On Mon, Jun 2, 2008 at 7:47 AM, John Krasnay [EMAIL PROTECTED] wrote:
On Sun, Jun 01, 2008 at 01:44:59PM -0700, Eelco Hillenius wrote:
1) Generifying* 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.
2) How strongly do you feel about your choice above?
[x] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
IMHO storing a model in a Component is more a convenience than a
fundamental part of component-ness. This may be part of the reason that
genericizing Component is so contentious.
I have many components with no model and many others, such as a
TextField that uses a parent's CompoundPropertyModel, the component has
a model but I really don't care about the type, since I never call
getModelObject(). In all these cases (which are easily the majority in
my experience), genericized Components would force me to deal with the
syntactic overhead of generics with absolutely zero value.
I'm all for genericizing certain components for which the model is
central (e.g. ListView and Item) but I think genericizing Component is
overkill, since it's relatively rare that I care about the type of a
component's model.
jk
-
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]
Re: users, please give us your opinion: what is your take on generics with Wicket
IMHO we should try to keep the topic on your take on generics, not on your take on others take on generics. But while we're at it: I've read over 100 emails on this thread, and nearly all of the ones against keeping generics like they are currently implemented are from people who do not fully understand them That *is* offending. How do you come to your conclusion that people don't understand generics? The following is not something I'd prefer, and I don't need to be a master in generics to form this opinion: DropDownChoiceFruit fruit = new DropDownChoiceFruit(fruit, new ModelFruit(), ...); new TextFieldInteger num = new TextFieldInteger(num, Integer.class) you can't call getModelObject() and get the right type - so generics didn't help you within your component IMHO generics should help in *using* components. you can't tell the rest of us that we shouldn't have a generic component because it wouldn't be used 70% of the time - that's only your use case I doubt that, anyone using CompoundPropertyModel will easily reach that percentage. It just seems wrong (to me) to generify Component just for one or two getters - weren't getters the root of all evil anyway? ;). Back to the topic: 1) Generifying 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. [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up ... what should I do otherwise, use JSF? (Just kidding) Sven Jeremy Thomerson schrieb: My vote: X - Can best be done like currently in the 1.4 branch, where models and components are both generified X - Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. I have to modify that last sentence, though - because I will continue using Wicket, because it's the best. But I have already upgraded all of my applications to use 1.4, and there wouldn't be any happily about it to back it out and stop using generics for me. They are too valuable to lose. I have been using 1.4 with generics since before M1 was released, with nearly half a dozen deployed production applications now running on either 1.4-M1 or M2. Without intending to offend anyone, the rest of my thoughts on this: I've read over 100 emails on this thread, and nearly all of the ones against keeping generics like they are currently implemented are from people who do not fully understand them and have not used them on a day-to-day basis. I'll grant you that the first switch to 1.4 was a little intimidating, but I had been wishing for generics in IModel since early 1.2 releases (fortunately I never switched to 2.0). Once you use them regularly, you will grow to appreciate them. I also agree that there are still some method signatures that may be done better - we'll put those on the wiki as we come across them. Some are saying we don't need to generify component - but then you can't call getModelObject() and get the right type - so generics didn't help you within your component. Where else will a generified model help you? Where are you using it that's not in a component? Some say we should not generify component, but they want getModelObject() to return the right type - they don't understand generics. There's a large discussion that says I don't use models in my components - interesting, because nearly all of the framework components use models - nearly all of my components use models - a model is a pretty core part of a component - it's what stores the data that the component is rendering or modifying - you can't tell the rest of us that we shouldn't have a generic component because it wouldn't be used 70% of the time - that's only your use case. When we talk about new users being intimidated by Wicket because of generics, it makes me think of the blog post by Martijn on Jonathan's statement don't hire wicket programmers [1] - a good programmer with a solid understanding of generics will not be intimidated when they start using this framework. This in no way implies that if you do not currently like the generics that you are a bad programmer. It only means that generics are still new to some, they have not used them enough yet to be really comfortable with them. They are very valuable, but yes, java could've implemented them better. So, we'd all better get good with generics - they've been in java for quite a while now, and they're here to stay. No reason Wicket shouldn't / can't do the same! Jeremy Thomerson 1 - http://martijndashorst.com/blog/2008/03/30/dont-hire-wicket-programmers/ On Sun, Jun 1, 2008 at 3:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 9:33 PM, Martin Funk [EMAIL PROTECTED] wrote: Hi Sebastiann, just for clarifying my understanding of the vocabulary: A_HomePage extends WebPage and B_HomePage extends WebPageVoid are both non-generified java classes. No the last one is generified.. The first one is a raw type. Esp. if the signature of 'public abstract Class? extends Page? getHomePage();' stays that way the HomePage can't be generified. No as far as i can see, the home page MUST be generified thats the whole problem with that constructo What would happen if we did: public abstract Class? extends Page and have a supresswarning in our code. johanm
Re: users, please give us your opinion: what is your take on generics with Wicket
I agree with the Class? extends Page with @SuppressWarnings in the framework code. It makes it easier, and there's no drawback either way. Jeremy On Mon, Jun 2, 2008 at 4:54 PM, Johan Compagner [EMAIL PROTECTED] wrote: On Mon, Jun 2, 2008 at 9:33 PM, Martin Funk [EMAIL PROTECTED] wrote: Hi Sebastiann, just for clarifying my understanding of the vocabulary: A_HomePage extends WebPage and B_HomePage extends WebPageVoid are both non-generified java classes. No the last one is generified.. The first one is a raw type. Esp. if the signature of 'public abstract Class? extends Page? getHomePage();' stays that way the HomePage can't be generified. No as far as i can see, the home page MUST be generified thats the whole problem with that constructo What would happen if we did: public abstract Class? extends Page and have a supresswarning in our code. johanm -- Jeremy Thomerson http://www.wickettraining.com
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [x] Should be avoided, I prefer the way 1.3 works. Because it works. Please improve the framework in functional details. Make it even easier to use. Make is less verbose. Keep the API stable. 2) How strongly do you feel about your choice above? [x] I might rethink upgrading if my choice doesn't win. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Point!--but i thought it is intended to extract a survey kind of info(with explanation if one has one) Just that the information here is overflowing with untraceable debates On Tue, Jun 3, 2008 at 12:47 AM, Bernard Niset [EMAIL PROTECTED] wrote: Hi Atul, Please read again the initial post from Eelco. He explicitly wrote: Note that it is not a vote; we only want to get an idea of what you think. and further away: Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions!. Bernard. atul singh a écrit : Hello everyone, I feel bad that a vote thread has been converted to one of discussion... At this moment wicket is *for *creating custom components. If these custom component writing gets complicated we will not be able to appreciate wicket as much(as much as we do now).Generics will complicate the *extend* at the moment for new user...I feel(after reading through everything). In core-java , fewer classes aim for extension by user. They rather are end product to be used, to be composed of. The best way still for wicket is *to implement generics partially *and* then start incorporating into OUT-OF-BOX(components less prone to extension) later on in further releases. The fact is that less people can make to wicket core-development team, and then who will maintain the bloat(meaning undesired syntactical features). Who will release non-generics versions for freshers. In Design Patterns I learnt about the open-closed principle. Closed for change and open for extension. Generics forces us to see into a new design pattern---Generify the the most closed only, based on use cases--If there is more of a need of extension of classes by end user AND there is flexibility while extending(wicket is one case which is flexible when you extend)--then wait, do not generify. * On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset [EMAIL PROTECTED] wrote: Hi all, [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. [X] I might rethink upgrading if my choice doesn't win. I didn't try wicket 1.4 yet, but I read questions and comments from users in this list. My impression so far has been that there has been a small design mistake in the way the current 1.4 implementation has been done. I perceive that IModelT is conceptually correct as a Model can be seen as a container of something (of type T). Writing DropDownChoiceT is a shortcut that does not seem conceptually correct as in this case, the component is not a container of type T but a container of type IModelT. So you should have something like DropDownChoiceIModelT (I know this not valid java). Generifying the Page component is even worse as possibly a page can hold components with different model types and not have a model type on its own. Also, wicket is designed to allow some components not to have model on their own and rely on the model stored in a parent component (very nice and powerful feature). Please note that using generic this way is already possible with wicket 1.3 if you define an interface that would be for instance IMyModelT extends IModel. For instance, I have a generic model defined as DetachableBeanModelK,T where K is the key type and T is the bean type. This type is indeed a container of a key element and of a bean element. I hope it helps, Bernard. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [X*] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. * Note that we just went live with http://online.ddpoker.com/ on 1.4 trunk using generics. I'd prefer not to backtrack, but will if that's what the developers decide. Having gone through a conversion of a brand new project about 1/2 way through, I can tell you that (a) it is not that hard, (b) it is ultimately worth it, (c) my knowledge of java is better due to having to learn generics better, (d) we feel we created cleaner/more maintainable code because of generics. I think wicket is great and seriously doubt, with good documentation, that using generics will turn people away. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17612641.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
