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 using 1.4 and up. -- 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-tp17589984p18965543.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
Just started using the half-way approach and I really miss the type safety of generified Component. 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. -- 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-tp17589984p18800407.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
Menu is a good idea! I worked on this piece a little bit, (Took some cues from Swing menu component), but i hit a dead end with keeping markup consistent. Probably because i dont know wicket well enough; But i am pretty sure it will be a good add on!. Rick On Thu, Jun 5, 2008 at 2:36 AM, [EMAIL PROTECTED] wrote: The way 1.3 works currently has been fine with me and any type mismatch in programming error usually result in crash with obvious location of error and easily fixed. So to me, it is optional and not very important. Switching to java 5 does not mean wicket must include generics, there are many other features in java 5 could be used to enhance wicket. and I feel the most helpful new facilities of wicket could be some powerful widgets, layouts, menus that one can use java api to produce (it could use any JS toolkits). Although it was contended that wicket is server side framework, without those widgets, it would not help spread its use as a Java web toolkit. It is true one could write javascript for some of them, but integration with java api would distinguish wicket from the rest. I know there are some projects like this but it would be nice to have it in wicket core as a strategic effort. It might not be worth a huge undertaking for a web framework, considering there are so many other equally crucial factors such as the widget issue above to make a web app successful. 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 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 Rocks! 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-tp17589984p18661192.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
Hello, my answers to the questions: 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 reason for my decision is that if a concept will be applied to a framework, then it should be applied thoroughly; in this case generics to all container-like types. But what are the advantages? In my understanding the following: - compile-time type safety - improved readability - improved robustness - eliminiation of casts. But are these the features, which are the most important to the users and deliver the most benefits? I think not the ways, but the objectives should be defined by the Wicket users. For me as a Wicket user the most important is to be more productive by writing less code. Eliminating casts doesn't mean this. Andras -- 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-tp17589984p18553155.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
Ditto Taranenko's reply. Static type checking is a real boon, and users should remember that using a generified framework is much easier than actually generifying the framework. Once the framework is properly generified, using it is typically quite easy, and clarity is significantly improved. I understand that users are worried about complexity, but the complexity of generics really rests upon the framework authors' shoulders, not the users of the framework. I believe within the next 2-3 years, as we see the phasing in of JDK 5-based app servers, that JEE programmers will become pretty comfortable with generics, as tricky as the syntax/semantics may be. 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. Thanks again for a great web framework! Ari -- 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-tp17589984p17995051.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
Hi *, My point of view, static type checking is more important as API cleareness. In any case using modern IDE make more help in this area. Some exercises in also useful for programmers (but not coders though :). Wicket was born as a framework for the qualified programmers. I think no reason why wicket should demote self for anybody, who can not understand generics. 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. [ ] 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? [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. 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-tp17589984p17902256.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
Eelco Hillenius 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 [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. [ ] 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? [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. 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] -- 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-tp17589984p17811756.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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I vote the same way. with almost the exact same sentiments. Wouter de Vaal 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. 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] - -- Philip A. Chapman Desktop and Web Application Development: Java, .NET, PostgreSQL, MySQL, MSSQL Linux, Windows 2000, Windows XP -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIUHzDAdpynRSGw3URAkdFAJsFWUKlbu27zE2LidYx3HdJUZt4cQCcDBX/ Ner0sbazi8jh/EllYZVgW1s= =WPF9 -END PGP SIGNATURE- - 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. **reason** Strong typing is my friend. Refactoring is my friend. The stronger and clearer we make typing throughout Wicket the happier I'll be. Code is written once and maintained a hundred thousand times. I'd always trade verbosity for maintainability. D - 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
Strong typing is my friend. Refactoring is my friend. The stronger and clearer we make typing throughout Wicket the happier I'll be. Code is written once and maintained a hundred thousand times. I'd always trade verbosity for maintainability. +1 for that --- very nice said! I totally agree :-) - 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
Strong typing is my friend. Refactoring is my friend. The stronger and clearer we make typing throughout Wicket the happier I'll be. Code is written once and maintained a hundred thousand times. I'd always trade verbosity for maintainability. Yes! Good summary! Stefan - 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. Regards, Ivo - 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 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 am just a little annoyed when a component not having a model causes generics warning. [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. _ MSN 中文网，最新时尚生活资讯，白领聚集门户。 http://cn.msn.com
RE: users, please give us your opinion: what is your take on generics with Wicket
The way 1.3 works currently has been fine with me and any type mismatch in programming error usually result in crash with obvious location of error and easily fixed. So to me, it is optional and not very important. Switching to java 5 does not mean wicket must include generics, there are many other features in java 5 could be used to enhance wicket. and I feel the most helpful new facilities of wicket could be some powerful widgets, layouts, menus that one can use java api to produce (it could use any JS toolkits). Although it was contended that wicket is server side framework, without those widgets, it would not help spread its use as a Java web toolkit. It is true one could write javascript for some of them, but integration with java api would distinguish wicket from the rest. I know there are some projects like this but it would be nice to have it in wicket core as a strategic effort. It might not be worth a huge undertaking for a web framework, considering there are so many other equally crucial factors such as the widget issue above to make a web app successful. 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
like matej already told you There is no default slot or field.. A component with no model doesnt have a a slot what so ever. johan On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: like i said, i dont mind removing the default slot if we add nice automatic detachment for fields. -igor On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: i dont think it exposes anything, or that anything is flawed. the component provides a slot for a default model - it is there totally out of convinience. i think what is flawed here is that we tied the two types via generics. It depends on how you phrase things. It is a fact that currently models and components are tightly bound because of 'getModelObject'. The main issue is that with 1.3 you can simply omit the model, whereas with generified components the choice to not use a model is explicit (whether you use void, or an annotation to ignore warnings). Very annoying if you ask me, and it triggered me to think that this is another hint that the one-one relationship between components and models like we have now is somewhat flawed. I'm not saying it totally stinks and that we should get rid of it tomorrow, just that it is something we might rethink. You know I'm a fan of rethinking stuff ;-) 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
i didnt mean the memory slot, i ment the actual default model each
component can have. if i can write something like this:
add(new webmarkupcontainer(foo) {
private imodelperson model;
protected void isvisible() { return model.getobject()!=null; });
then i am perfectly happy. notice how there is no explicit ondetach()
to detach the model. also notice how not having a default model slot
really removes the need for typing the component itself, i can
implement my own typed getmodel() easily. the only thing that breaks
here is wrapping since we no longer have a setmodel...something to
think about
-igor
On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner [EMAIL PROTECTED] wrote:
like matej already told you
There is no default slot or field..
A component with no model doesnt have a a slot what so ever.
johan
On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
like i said, i dont mind removing the default slot if we add nice
automatic detachment for fields.
-igor
On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
i dont think it exposes anything, or that anything is flawed. the
component provides a slot for a default model - it is there totally
out of convinience. i think what is flawed here is that we tied the
two types via generics.
It depends on how you phrase things. It is a fact that currently
models and components are tightly bound because of 'getModelObject'.
The main issue is that with 1.3 you can simply omit the model, whereas
with generified components the choice to not use a model is explicit
(whether you use void, or an annotation to ignore warnings). Very
annoying if you ask me, and it triggered me to think that this is
another hint that the one-one relationship between components and
models like we have now is somewhat flawed. I'm not saying it totally
stinks and that we should get rid of it tomorrow, just that it is
something we might rethink. You know I'm a fan of rethinking stuff ;-)
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]
-
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] Should be avoided, I prefer the way 1.3 works. Because sometimes I still run into web servers like websphere 5.x that still depend on jdk 1.4 (also some tomcat 5.5 hosting sites). The beauty of Wicket is its simplicity and adding generics doesn't seem be worth the cost. I like generics but I get tons of warnings in Eclipse now about wicket generics just from using components. Please focus on making Wicket even more concise, elegant, and easy to use... seems like thats always where web frameworks fail... they tack on so many features and abstract framework requirements that it becomes a mess. 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-tp17589984p17673404.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
For that we have 1.3 1.4 will be java 5 On 6/5/08, pkcinna [EMAIL PROTECTED] wrote: [x] Should be avoided, I prefer the way 1.3 works. Because sometimes I still run into web servers like websphere 5.x that still depend on jdk 1.4 (also some tomcat 5.5 hosting sites). The beauty of Wicket is its simplicity and adding generics doesn't seem be worth the cost. I like generics but I get tons of warnings in Eclipse now about wicket generics just from using components. Please focus on making Wicket even more concise, elegant, and easy to use... seems like thats always where web frameworks fail... they tack on so many features and abstract framework requirements that it becomes a mess. 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-tp17589984p17673404.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
This might also screw up stuff like CompoundPropertyModel, no? We
discussed this a bit on ##wicket.
On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
i didnt mean the memory slot, i ment the actual default model each
component can have. if i can write something like this:
add(new webmarkupcontainer(foo) {
private imodelperson model;
protected void isvisible() { return model.getobject()!=null; });
then i am perfectly happy. notice how there is no explicit ondetach()
to detach the model. also notice how not having a default model slot
really removes the need for typing the component itself, i can
implement my own typed getmodel() easily. the only thing that breaks
here is wrapping since we no longer have a setmodel...something to
think about
-igor
On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner [EMAIL PROTECTED] wrote:
like matej already told you
There is no default slot or field..
A component with no model doesnt have a a slot what so ever.
johan
On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
like i said, i dont mind removing the default slot if we add nice
automatic detachment for fields.
-igor
On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
i dont think it exposes anything, or that anything is flawed. the
component provides a slot for a default model - it is there totally
out of convinience. i think what is flawed here is that we tied the
two types via generics.
It depends on how you phrase things. It is a fact that currently
models and components are tightly bound because of 'getModelObject'.
The main issue is that with 1.3 you can simply omit the model, whereas
with generified components the choice to not use a model is explicit
(whether you use void, or an annotation to ignore warnings). Very
annoying if you ask me, and it triggered me to think that this is
another hint that the one-one relationship between components and
models like we have now is somewhat flawed. I'm not saying it totally
stinks and that we should get rid of it tomorrow, just that it is
something we might rethink. You know I'm a fan of rethinking stuff ;-)
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]
-
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
yes. thats what i meant by wrapping. when/if we evaluate this we can
obviously put more thought into what it will effect and how to make it
all work. right now it was just a two minute idea i had, and it may
yet forever stay that way.
-igor
On Thu, Jun 5, 2008 at 10:16 AM, James Carman
[EMAIL PROTECTED] wrote:
This might also screw up stuff like CompoundPropertyModel, no? We
discussed this a bit on ##wicket.
On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
i didnt mean the memory slot, i ment the actual default model each
component can have. if i can write something like this:
add(new webmarkupcontainer(foo) {
private imodelperson model;
protected void isvisible() { return model.getobject()!=null; });
then i am perfectly happy. notice how there is no explicit ondetach()
to detach the model. also notice how not having a default model slot
really removes the need for typing the component itself, i can
implement my own typed getmodel() easily. the only thing that breaks
here is wrapping since we no longer have a setmodel...something to
think about
-igor
On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner [EMAIL PROTECTED] wrote:
like matej already told you
There is no default slot or field..
A component with no model doesnt have a a slot what so ever.
johan
On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
like i said, i dont mind removing the default slot if we add nice
automatic detachment for fields.
-igor
On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
i dont think it exposes anything, or that anything is flawed. the
component provides a slot for a default model - it is there totally
out of convinience. i think what is flawed here is that we tied the
two types via generics.
It depends on how you phrase things. It is a fact that currently
models and components are tightly bound because of 'getModelObject'.
The main issue is that with 1.3 you can simply omit the model, whereas
with generified components the choice to not use a model is explicit
(whether you use void, or an annotation to ignore warnings). Very
annoying if you ask me, and it triggered me to think that this is
another hint that the one-one relationship between components and
models like we have now is somewhat flawed. I'm not saying it totally
stinks and that we should get rid of it tomorrow, just that it is
something we might rethink. You know I'm a fan of rethinking stuff ;-)
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]
-
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
Personally, I find CompoundPropertyModel too magicy for my tastes
anyway. Yes, it's very convenient to just use property names for
component ids and it all just works out fine, but that can sometimes
be difficult to understand from a new person's perspective. When
learning a technology, I don't really like it when folk say just do
it this way; it works; trust me. When I first started using
CompoundPropertyModel, I had these questions (and I'm sure others, but
this is all I can think of right now)?
1. How far up the chain does a Component go looking for something to
base its property expression on?
2. If I have a model on a Component in between my Component and the
Component containing the CPM, will it be smart enough to skip over
the intermediate model and travel up to the real one I want?
3. What happens if I change property names!?
Maybe it's just me and I like to know how things work! :) I used to
take apart my toys as a kid and I could never quite get them back
together the way they came.
James
On Thu, Jun 5, 2008 at 1:20 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
yes. thats what i meant by wrapping. when/if we evaluate this we can
obviously put more thought into what it will effect and how to make it
all work. right now it was just a two minute idea i had, and it may
yet forever stay that way.
-igor
On Thu, Jun 5, 2008 at 10:16 AM, James Carman
[EMAIL PROTECTED] wrote:
This might also screw up stuff like CompoundPropertyModel, no? We
discussed this a bit on ##wicket.
On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
i didnt mean the memory slot, i ment the actual default model each
component can have. if i can write something like this:
add(new webmarkupcontainer(foo) {
private imodelperson model;
protected void isvisible() { return model.getobject()!=null; });
then i am perfectly happy. notice how there is no explicit ondetach()
to detach the model. also notice how not having a default model slot
really removes the need for typing the component itself, i can
implement my own typed getmodel() easily. the only thing that breaks
here is wrapping since we no longer have a setmodel...something to
think about
-igor
On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner [EMAIL PROTECTED] wrote:
like matej already told you
There is no default slot or field..
A component with no model doesnt have a a slot what so ever.
johan
On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
like i said, i dont mind removing the default slot if we add nice
automatic detachment for fields.
-igor
On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
i dont think it exposes anything, or that anything is flawed. the
component provides a slot for a default model - it is there totally
out of convinience. i think what is flawed here is that we tied the
two types via generics.
It depends on how you phrase things. It is a fact that currently
models and components are tightly bound because of 'getModelObject'.
The main issue is that with 1.3 you can simply omit the model, whereas
with generified components the choice to not use a model is explicit
(whether you use void, or an annotation to ignore warnings). Very
annoying if you ask me, and it triggered me to think that this is
another hint that the one-one relationship between components and
models like we have now is somewhat flawed. I'm not saying it totally
stinks and that we should get rid of it tomorrow, just that it is
something we might rethink. You know I'm a fan of rethinking stuff ;-)
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]
-
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
There are plenty of cases where there isn't much risk and where using
CompoundPropertyModels is just convenient and leads to nicer readable
(imho) code. I use those models quite a bit, and I like them. I use
plenty of other (custom LDMs mainly) as well though.
Eelco
On Thu, Jun 5, 2008 at 10:29 AM, James Carman
[EMAIL PROTECTED] wrote:
Personally, I find CompoundPropertyModel too magicy for my tastes
anyway. Yes, it's very convenient to just use property names for
component ids and it all just works out fine, but that can sometimes
be difficult to understand from a new person's perspective. When
learning a technology, I don't really like it when folk say just do
it this way; it works; trust me. When I first started using
CompoundPropertyModel, I had these questions (and I'm sure others, but
this is all I can think of right now)?
1. How far up the chain does a Component go looking for something to
base its property expression on?
2. If I have a model on a Component in between my Component and the
Component containing the CPM, will it be smart enough to skip over
the intermediate model and travel up to the real one I want?
3. What happens if I change property names!?
Maybe it's just me and I like to know how things work! :) I used to
take apart my toys as a kid and I could never quite get them back
together the way they came.
James
On Thu, Jun 5, 2008 at 1:20 PM, Igor Vaynberg [EMAIL PROTECTED] wrote:
yes. thats what i meant by wrapping. when/if we evaluate this we can
obviously put more thought into what it will effect and how to make it
all work. right now it was just a two minute idea i had, and it may
yet forever stay that way.
-igor
On Thu, Jun 5, 2008 at 10:16 AM, James Carman
[EMAIL PROTECTED] wrote:
This might also screw up stuff like CompoundPropertyModel, no? We
discussed this a bit on ##wicket.
On Thu, Jun 5, 2008 at 11:44 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
i didnt mean the memory slot, i ment the actual default model each
component can have. if i can write something like this:
add(new webmarkupcontainer(foo) {
private imodelperson model;
protected void isvisible() { return model.getobject()!=null; });
then i am perfectly happy. notice how there is no explicit ondetach()
to detach the model. also notice how not having a default model slot
really removes the need for typing the component itself, i can
implement my own typed getmodel() easily. the only thing that breaks
here is wrapping since we no longer have a setmodel...something to
think about
-igor
On Thu, Jun 5, 2008 at 12:53 AM, Johan Compagner [EMAIL PROTECTED] wrote:
like matej already told you
There is no default slot or field..
A component with no model doesnt have a a slot what so ever.
johan
On Wed, Jun 4, 2008 at 11:34 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
like i said, i dont mind removing the default slot if we add nice
automatic detachment for fields.
-igor
On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
i dont think it exposes anything, or that anything is flawed. the
component provides a slot for a default model - it is there totally
out of convinience. i think what is flawed here is that we tied the
two types via generics.
It depends on how you phrase things. It is a fact that currently
models and components are tightly bound because of 'getModelObject'.
The main issue is that with 1.3 you can simply omit the model, whereas
with generified components the choice to not use a model is explicit
(whether you use void, or an annotation to ignore warnings). Very
annoying if you ask me, and it triggered me to think that this is
another hint that the one-one relationship between components and
models like we have now is somewhat flawed. I'm not saying it totally
stinks and that we should get rid of it tomorrow, just that it is
something we might rethink. You know I'm a fan of rethinking stuff ;-)
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]
-
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 Thu, Jun 5, 2008 at 10:20 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: yes. thats what i meant by wrapping. when/if we evaluate this we can obviously put more thought into what it will effect and how to make it all work. right now it was just a two minute idea i had, and it may yet forever stay that way. I think it would be good to discuss this when everyone is read for it. I for one would like to explore alternatives to what we currently have. But to have that discussion now would be a waste of our time. 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
On Thu, Jun 5, 2008 at 1:45 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 10:20 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: yes. thats what i meant by wrapping. when/if we evaluate this we can obviously put more thought into what it will effect and how to make it all work. right now it was just a two minute idea i had, and it may yet forever stay that way. I think it would be good to discuss this when everyone is read for it. I for one would like to explore alternatives to what we currently have. But to have that discussion now would be a waste of our time. Right, we need to figure out what we're going to do for 1.4. Have we decided on that? It seems like a lot of folks like the idea of making the model methods non-final on Component, thereby allowing components to type themselves by overriding them (using JDK5 covariant return types) when it makes sense (ListView, Item, etc.). This hybrid approach seems like it would be a good compromise. - 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
Right, we need to figure out what we're going to do for 1.4. Have we decided on that? It seems like a lot of folks like the idea of making the model methods non-final on Component, thereby allowing components to type themselves by overriding them (using JDK5 covariant return types) when it makes sense (ListView, Item, etc.). This hybrid approach seems like it would be a good compromise. I'm still on the fence. I was thinking that it might make a good topic to talk about - and decide upon - next week, when everyone has had a good rest and the dust has settled down etc. :-) 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
next week a good rest? next week i dont have much rest.. I am on vacation! Bern, Switzerland! johan On Thu, Jun 5, 2008 at 8:05 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Right, we need to figure out what we're going to do for 1.4. Have we decided on that? It seems like a lot of folks like the idea of making the model methods non-final on Component, thereby allowing components to type themselves by overriding them (using JDK5 covariant return types) when it makes sense (ListView, Item, etc.). This hybrid approach seems like it would be a good compromise. I'm still on the fence. I was thinking that it might make a good topic to talk about - and decide upon - next week, when everyone has had a good rest and the dust has settled down etc. :-) 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
Johan Compagner wrote next week i dont have much rest.. I am on vacation! Bern, Switzerland! You are visiting an EM match? That's not a rest? :-) - 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 2008/06/02, at 5:44, Eelco Hillenius 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. For me, the most important thing is that component's getModelObject() method returns a object with correct type, which the IModel have, without casting. If it will be not realized, generifying Wicket have no mean. it is needed generifying both of components and models to realize that. If components will be not generified, getModelObject() method will return Object type always, then I need casting it. I often usegetModelObject() method. 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. However, I can understand that the way like PageVoid, LinkVoid is verbose. So we can avoid the verbosity creating some generic classes for components. Like: - PageT - GenericPage extends BasePageVoid If I want not write PageVoid, you can simply use GenericPage class instead. -- Tsutomu YANO benbrand at mac.com Tokyo, Japan - 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 10:37 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: 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. Well, like I stated I just wanted to get a hunch of what people think, not so much an informed discussion. I think it is very clear now that whatever choice we'll ultimately stick to, it will make part of our user base unhappy, and might have to do some evangelizing to get the changes accepted by everyone (or most) :-) As for speculation... I don't agree. I haven't converted yet, but it is easy enough to just look at any old piece of code I'm working on now and imagine what it will look like after changing to 1.4. 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
On Tue, Jun 3, 2008 at 11:30 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: 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. As for speculation... I don't agree. I haven't converted yet, but it is easy enough to just look at any old piece of code I'm working on now and imagine what it will look like after changing to 1.4. and there are also a lot of pain points that you will not imagine that do exist :) i am wondering how many of the keep as is in trunk votes came from people who only imagined what their code would look like and havent actually hit the numerous pain points those of us who did code gainst it hit. i was of the generify component and model mind while i was generifying the framework, but after coding against it i began to see some of the ugliness and now my mind is almost changed. -igor 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
i was of the generify component and model mind while i was generifying the framework, but after coding against it i began to see some of the ugliness and now my mind is almost changed. yep, day to day usage is the main point. i came to that conclusion as well when i was trying to migrate somewhat non-trivial use of wicket to 1.4 base. the standard components like link et al aren't the real problem (though it doesn't look pretty), it gets complicated when you're using non-trivial components (like datatable and their dependents) where the type on the component gets in your way. - 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
Igor Vaynberg wrote
i am wondering how many of the keep as is in trunk votes came from
people who only imagined what their code would look like and havent
actually hit the numerous pain points those of us who did code gainst
it hit.
I'm one of the keep as is in trunk users and I use 1.4 trunk from the
beginning. I use it in a big real world application. But: I am one of
the former 2.0 users and accustomed to generic Components in Wicket.
Maybe I have made my workaround strategy for some generic problems more
than a year ago.
One experience I made was that I realized that I made no use of Models
when I startet using Wicket from 1.0. Instead of having
public class MyPanel extends PanelMyData
public MyPanel(String id, IModelMyData model) {
...
I used constructs like
public class MyPanel extends Panel
public MyPanel(String id, MyData myData) {
...
like I was used to do in other frameworks. The second one was the only
way to have a typesafe treatment of MyData when Model was non generic.
It took a while to realize that the Models in Wicket are very usefull
thing and the tight Component-Model coupling leads to better
Applications
Maybe the posts like I do not use Models or Only 20% or our
components have Models come from the same background as my early wicket
adoption.
Stefan
-
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
it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. 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 the only real other way is what is already possible Just dont keep references to the Component (just add them to there parents) and keep references to the models of those components. and work with models only johan On Wed, Jun 4, 2008 at 10:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. 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
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. 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
There are also implementation issues that need to be considered. Currently the model is stored in a way that it doesn't take any place when not used. Having multiple models is rare, however, having one model that can (but doesn't have to) be used is more common imho. Wicket is kinda optimized for the later, so if you don't use the model there is no runtime cost associated. If we didn't have default model slot this would be more difficult to achieve. -Matej On Wed, Jun 4, 2008 at 12:37 PM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. 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] - 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
soo
interface IModelComponentT
{
public IModelT getModel()
}
and remove getModel/getModelObject methods from component itself?
But then everybody that does use models have to implement it..
On Wed, Jun 4, 2008 at 12:37 PM, James Carman [EMAIL PROTECTED]
wrote:
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
it all depends, on how and what you're developing.
Yeah. I actually use less and less models in the regular way nowadays.
I use plenty of panels (the app I work on hardly uses separate pages)
that nest other panels in them (typically detail views or dialogs)
that reuse models of the parent. But indeed YMMV.
Personally, I think the whole generics business exposes that the
one-one relation between components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor, but as generics aren't as 'optional' it is all very in
your face suddenly.
I think on the longer term (post 1.4) we should re-think how models
work in Wicket. See if we can find an elegant way to make this more
flexible (I'm not in favor of the id based thing someone posted
earlier btw) without breaking the whole world.
We discussed this on ##wicket yesterday. I asked why we have models
on all components and someone pointed out that the main reason was
about the detach stuff I believe. But, couldn't that be solved by
having some components that implement something like IModelDriven (or
IModelBacked or whatever) and the detach logic could apply to only
those components? Also, someone has pointed out that when they create
their own components, they sometimes (such as in Palette) have
multiple models that they deal with. Allowing components to name
their models what they want would be nice, too.
FWIW, I'm still on the fence when it comes to whether we should go for
a full or partial (models only) implementation of generics, though I'm
leaning towards partial.
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
I don't really think this is the right discussion we should be having now :)
Maybe 1.5 would be the right release for changes like that (if they
are justified, which i'm not really convinced it is. Anyway, as I said
before, storing (single) model in component has no overhead, so I
don't really see the point. Maybe we could make the methods protected
and components that actually use the default model would make them
public, dunno.
-Matej
On Wed, Jun 4, 2008 at 1:59 PM, Johan Compagner [EMAIL PROTECTED] wrote:
soo
interface IModelComponentT
{
public IModelT getModel()
}
and remove getModel/getModelObject methods from component itself?
But then everybody that does use models have to implement it..
On Wed, Jun 4, 2008 at 12:37 PM, James Carman [EMAIL PROTECTED]
wrote:
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
it all depends, on how and what you're developing.
Yeah. I actually use less and less models in the regular way nowadays.
I use plenty of panels (the app I work on hardly uses separate pages)
that nest other panels in them (typically detail views or dialogs)
that reuse models of the parent. But indeed YMMV.
Personally, I think the whole generics business exposes that the
one-one relation between components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor, but as generics aren't as 'optional' it is all very in
your face suddenly.
I think on the longer term (post 1.4) we should re-think how models
work in Wicket. See if we can find an elegant way to make this more
flexible (I'm not in favor of the id based thing someone posted
earlier btw) without breaking the whole world.
We discussed this on ##wicket yesterday. I asked why we have models
on all components and someone pointed out that the main reason was
about the detach stuff I believe. But, couldn't that be solved by
having some components that implement something like IModelDriven (or
IModelBacked or whatever) and the detach logic could apply to only
those components? Also, someone has pointed out that when they create
their own components, they sometimes (such as in Palette) have
multiple models that they deal with. Allowing components to name
their models what they want would be nice, too.
FWIW, I'm still on the fence when it comes to whether we should go for
a full or partial (models only) implementation of generics, though I'm
leaning towards partial.
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]
-
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 even have an interface? just detach all imodel fields via reflection! -igor On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. 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] - 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
and if i store it in metadata ;) On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: why even have an interface? just detach all imodel fields via reflection! -igor On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. 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] - 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 wrote: et an idea of what you think. 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. But turned off where not appropriate. Eelco Hillenius wrote: 2) How strongly do you feel about your choice above? [ ] [x] It would make me sad to lose generic components : ( -- 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-tp17589984p17651064.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
you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... -igor On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner [EMAIL PROTECTED] wrote: and if i store it in metadata ;) On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: why even have an interface? just detach all imodel fields via reflection! -igor On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. 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] - 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
Having multiple models is rare, however, having one model that can (but doesn't have to) be used is more common imho. Not that rare if I look at my code, especially if you take panels and fragments into account. I have plenty of places where I use two or three models. Wicket is kinda optimized for the later, so if you don't use the model there is no runtime cost associated. If we didn't have default model slot this would be more difficult to achieve. The problem with generics now is that the model isn't as optional anymore. So you'd have to use void or whatever. 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 was talking about the model slot. If you don't have a model in component it doesn't cost you anything. -Matej On Wed, Jun 4, 2008 at 6:49 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Having multiple models is rare, however, having one model that can (but doesn't have to) be used is more common imho. Not that rare if I look at my code, especially if you take panels and fragments into account. I have plenty of places where I use two or three models. Wicket is kinda optimized for the later, so if you don't use the model there is no runtime cost associated. If we didn't have default model slot this would be more difficult to achieve. The problem with generics now is that the model isn't as optional anymore. So you'd have to use void or whatever. 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
On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... I tried to write this two days ago, but wasn't able to pull it off... I wrote an instantiation listener that introspected on the fields of components and replaced IModel members with a proxy. These proxies would register themselves with the request cycle for cleaning up whenever the getObject was called, and the request cycle then would go through the list of registered models and detach them at the end of the request. The problem I ran into however is that these members can be final, assigned at a later stage (typically are actually) and such. But if there is some way to automatically detach model members, we could get rid of the model member in component and instead just let components have models by default where it actually always makes sense, such as form components. Anyway, that's something for 1.5. If it is fixable, I think that would be the way out of the generics controversy :-) 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
On Wed, Jun 4, 2008 at 9:52 AM, Matej Knopp [EMAIL PROTECTED] wrote: I was talking about the model slot. If you don't have a model in component it doesn't cost you anything. The cost in this case is the fact that having the model slot, even when not used, results in the assumption that a component is typed. 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
but IModel implementations can have Imodels inside too And the LDM doesn't play wel with detach unfortunately as it keeps an attached boolean that prevents the detach from entering the nested IModel Martijn On Wed, Jun 4, 2008 at 6:43 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... -igor On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner [EMAIL PROTECTED] wrote: and if i store it in metadata ;) On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: why even have an interface? just detach all imodel fields via reflection! -igor On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. 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] - 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]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Wed, Jun 4, 2008 at 10:05 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: but IModel implementations can have Imodels inside too Whether done automatically or by components as we do now, ultimately the calls to detach will be the same, right? 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
sounds way too complicated to me dude...
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
with proper caching of the actual fields lookup this should be pretty performant
-igor
On Wed, Jun 4, 2008 at 10:03 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
you still have ondetach()...but for convinience we can automatically
detach any imodel fields, i actually wanted to do this for a while...
I tried to write this two days ago, but wasn't able to pull it off...
I wrote an instantiation listener that introspected on the fields of
components and replaced IModel members with a proxy. These proxies
would register themselves with the request cycle for cleaning up
whenever the getObject was called, and the request cycle then would go
through the list of registered models and detach them at the end of
the request. The problem I ran into however is that these members can
be final, assigned at a later stage (typically are actually) and such.
But if there is some way to automatically detach model members, we
could get rid of the model member in component and instead just let
components have models by default where it actually always makes
sense, such as form components.
Anyway, that's something for 1.5. If it is fixable, I think that would
be the way out of the generics controversy :-)
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
If besides formcomponent you get links/buttons and so on, then i still think the example i see of verbosity is still there, like dropdownchoice is then generified?? On 6/4/08, Eelco Hillenius [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... I tried to write this two days ago, but wasn't able to pull it off... I wrote an instantiation listener that introspected on the fields of components and replaced IModel members with a proxy. These proxies would register themselves with the request cycle for cleaning up whenever the getObject was called, and the request cycle then would go through the list of registered models and detach them at the end of the request. The problem I ran into however is that these members can be final, assigned at a later stage (typically are actually) and such. But if there is some way to automatically detach model members, we could get rid of the model member in component and instead just let components have models by default where it actually always makes sense, such as form components. Anyway, that's something for 1.5. If it is fixable, I think that would be the way out of the generics controversy :-) 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
On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
sounds way too complicated to me dude...
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
with proper caching of the actual fields lookup this should be pretty
performant
Maybe. I was trying to avoid having to introspect on every single detachment.
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
On Wed, Jun 4, 2008 at 10:23 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
sounds way too complicated to me dude...
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
with proper caching of the actual fields lookup this should be pretty
performant
Maybe. I was trying to avoid having to introspect on every single detachment.
well, like i said, just cache it in a global map.
ConcurrentHashMapClassComponent,CollectionField. we do this all
over the place, eg propertyresolver. that way you can even only cache
IModel fields, so the loop becomes even tighter.
-igor
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
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
+1
I'm also for moving getModel()/getModelObject() out of Component and only
putting them in things that really use models, like Label and
FormComponent...
I agree, though, that this should probably wait for 1.5...
--
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-tp17589984p17652189.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
We should definitely discuss this after 1.4.
-Matej
On Wed, Jun 4, 2008 at 7:30 PM, Patrick Angeles [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
+1
I'm also for moving getModel()/getModelObject() out of Component and only
putting them in things that really use models, like Label and
FormComponent...
I agree, though, that this should probably wait for 1.5...
--
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-tp17589984p17652189.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
So it would be no generics or it would be: MyComponentCompoundPropertyModel mycom = new MyComponentCompoundPropertyModel(); and I was saying that the suppress *should not* be in the API because people need the ability to control that sort of thing at their own code level, which should address your issue. - Brill Pappin On Tue, Jun 3, 2008 at 11:54 PM, Mike Comb [EMAIL PROTECTED] wrote: Well, in our case it would almost never be: 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] - 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
Opinion, not statement :) But i get where your coming from. - Brill On Tue, Jun 3, 2008 at 11:29 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: 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
Re: users, please give us your opinion: what is your take on generics with Wicket
I *have* used the m1 release and although its not yet an RC and there are some issues to work out, it was a breath of fresh air. The biggest problem I had was understanding what kind of type to set things to, but once I sorted that out for a component, it made working with it later much easier. It not clean yet which made it a bit of a pain and I can understand why some would balk, but I can *definitely* see the joy on the horizon. that's my personal experience rather that my professional opinion. - Brill Pappin On Wed, Jun 4, 2008 at 2:40 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:30 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: 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. As for speculation... I don't agree. I haven't converted yet, but it is easy enough to just look at any old piece of code I'm working on now and imagine what it will look like after changing to 1.4. and there are also a lot of pain points that you will not imagine that do exist :) i am wondering how many of the keep as is in trunk votes came from people who only imagined what their code would look like and havent actually hit the numerous pain points those of us who did code gainst it hit. i was of the generify component and model mind while i was generifying the framework, but after coding against it i began to see some of the ugliness and now my mind is almost changed. -igor 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] - 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 the type of component is getting in the way doesn't that mean the problem (non-trivial) component may need to be redesigned? - Brill Pappin On Wed, Jun 4, 2008 at 2:50 AM, Jan Kriesten [EMAIL PROTECTED] wrote: i was of the generify component and model mind while i was generifying the framework, but after coding against it i began to see some of the ugliness and now my mind is almost changed. yep, day to day usage is the main point. i came to that conclusion as well when i was trying to migrate somewhat non-trivial use of wicket to 1.4 base. the standard components like link et al aren't the real problem (though it doesn't look pretty), it gets complicated when you're using non-trivial components (like datatable and their dependents) where the type on the component gets in your way. - 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 that and I think that is *the* key point. If implementing regular language features exposes a flaw, fix the flaw. I'm one of those that would rather have to refactor my code to upgrade to a new major version than try and work around some flaw just to maintain compatibility. - Brill Pappin On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: [...] Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. [...] - 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
Thats a pretty major api change (although it looks simple) maybe that
should be in the next major release?
- Brill
On Wed, Jun 4, 2008 at 1:30 PM, Patrick Angeles [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
+1
I'm also for moving getModel()/getModelObject() out of Component and only
putting them in things that really use models, like Label and
FormComponent...
I agree, though, that this should probably wait for 1.5...
--
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-tp17589984p17652189.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 dont think it exposes anything, or that anything is flawed. the component provides a slot for a default model - it is there totally out of convinience. i think what is flawed here is that we tied the two types via generics. for example, sometimes i want to have a webmarkupcontainer with a model and sometimes without. -igor On Wed, Jun 4, 2008 at 11:30 AM, Brill Pappin [EMAIL PROTECTED] wrote: I agree with that and I think that is *the* key point. If implementing regular language features exposes a flaw, fix the flaw. I'm one of those that would rather have to refactor my code to upgrade to a new major version than try and work around some flaw just to maintain compatibility. - Brill Pappin On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: [...] Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. [...] - 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 Wed, Jun 4, 2008 at 11:35 AM, Brill Pappin [EMAIL PROTECTED] wrote: Thats a pretty major api change (although it looks simple) maybe that should be in the next major release? It's something we can consider yeah. We'll have to think it through and get back to the drawing board to see what that means for how components and models work together though. Consistency is very important in an API like Wicket's, and consistency is imho a big + in how models and components currently work together. 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 have to admit I haven't read thru all of this thread, so my answer might be to something else... But here we go: I think we actually do something very similar to this in our system, we automatically detach any instances of jpa-enitities (replacing them with a surrogate with only the class and id) and then get them again from the db-cache if the page is reconstructed again. So far it works like a charm and the programming model is very convinient. Just dump whatever entity you like as member of a component and it is automatically detached and then loaded back when needed. I implemented this by hooking in to serialization, just checking each object in ObjectOutputStream.replaceObject and ObjectInputStream.resolveObject. Also had to use my own PageMapEntries to get a suitable hook. Might work as an idea for your implementation perhaps? // Daniel jalbum.net On 2008-06-04, at 19:03, Eelco Hillenius wrote: On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... I tried to write this two days ago, but wasn't able to pull it off... I wrote an instantiation listener that introspected on the fields of components and replaced IModel members with a proxy. These proxies would register themselves with the request cycle for cleaning up whenever the getObject was called, and the request cycle then would go through the list of registered models and detach them at the end of the request. The problem I ran into however is that these members can be final, assigned at a later stage (typically are actually) and such. But if there is some way to automatically detach model members, we could get rid of the model member in component and instead just let components have models by default where it actually always makes sense, such as form components. Anyway, that's something for 1.5. If it is fixable, I think that would be the way out of the generics controversy :-) 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
I implemented this by hooking in to serialization, just checking each object in ObjectOutputStream.replaceObject and ObjectInputStream.resolveObject. Also had to use my own PageMapEntries to get a suitable hook. Might work as an idea for your implementation perhaps? That's a cool idea for individual projects. For Wicket in general however, the problem would be that it wouldn't work for every session store (it wouldn't for instance for HttpSessionStore which doesn't serialize on each request). Also, 1.3's default session store serializes on each request, but does not reuse that serialized instance until the back button is used (or if you're doing session replication and come in through another node I guess). Are you sure your detachment works like you think it does? 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
Also, 1.3's default session store serializes on each request, but does not reuse that serialized instance until the back button is used (or if you're doing session replication and come in through another node I guess). It keeps the 'current' page in memory, and reuses that when it can. 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
On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: i dont think it exposes anything, or that anything is flawed. the component provides a slot for a default model - it is there totally out of convinience. i think what is flawed here is that we tied the two types via generics. It depends on how you phrase things. It is a fact that currently models and components are tightly bound because of 'getModelObject'. The main issue is that with 1.3 you can simply omit the model, whereas with generified components the choice to not use a model is explicit (whether you use void, or an annotation to ignore warnings). Very annoying if you ask me, and it triggered me to think that this is another hint that the one-one relationship between components and models like we have now is somewhat flawed. I'm not saying it totally stinks and that we should get rid of it tomorrow, just that it is something we might rethink. You know I'm a fan of rethinking stuff ;-) 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 implemented this by hooking in to serialization, just checking each object in ObjectOutputStream.replaceObject and ObjectInputStream.resolveObject. Also had to use my own PageMapEntries to get a suitable hook. Might work as an idea for your implementation perhaps? That's a cool idea for individual projects. For Wicket in general however, the problem would be that it wouldn't work for every session store (it wouldn't for instance for HttpSessionStore which doesn't serialize on each request). Also, 1.3's default session store serializes on each request, but does not reuse that serialized instance until the back button is used (or if you're doing session replication and come in through another node I guess). Are you sure your detachment works like you think it does? Well... I haven't actually hooked into the SessionStore but instead have implemented a special PageMapEntry that stores a serialized page with my special serialization (hooked in by overridden getPageMapEntry(...) in my BasePage). The special serialization takes place when the page is put into the pagemap. If the pagemap entry should be stored to disk later it is an object with serialized data that gets serialized again. I'm pretty sure it works as I intended and it might be generalized. The programming model sure is very nifty. // Daniel jalbum.net - 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
Well... I haven't actually hooked into the SessionStore but instead have implemented a special PageMapEntry that stores a serialized page with my special serialization (hooked in by overridden getPageMapEntry(...) in my BasePage). The special serialization takes place when the page is put into the pagemap. If the pagemap entry should be stored to disk later it is an object with serialized data that gets serialized again. I'm pretty sure it works as I intended and it might be generalized. The programming model sure is very nifty. Yeah, that sounds right. Nice :-) 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
not just getModelObject() also the toString variants for rendering and so on The component has to get its data. Ok this isnt the case for Component itself or the containers But for Labels, Links, buttons and all form components it is pretty needed. So the component should be able to access any way so it can also detach it.. johan On Wed, Jun 4, 2008 at 9:23 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: i dont think it exposes anything, or that anything is flawed. the component provides a slot for a default model - it is there totally out of convinience. i think what is flawed here is that we tied the two types via generics. It depends on how you phrase things. It is a fact that currently models and components are tightly bound because of 'getModelObject'. The main issue is that with 1.3 you can simply omit the model, whereas with generified components the choice to not use a model is explicit (whether you use void, or an annotation to ignore warnings). Very annoying if you ask me, and it triggered me to think that this is another hint that the one-one relationship between components and models like we have now is somewhat flawed. I'm not saying it totally stinks and that we should get rid of it tomorrow, just that it is something we might rethink. You know I'm a fan of rethinking stuff ;-) 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
Brill Pappin wrote: 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. Just out of curiosity: Do you have an example for this or some pointer to someone who has ? -- 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-tp17589984p17656527.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
A component could add a behavior for each model it wants to use:
public class ModelBehavior extends AbstractBehavior {
private IModel model;
public ModelBehavior(IModel model) {
this.model = model;
}
public void detach(Component component) {
this.model.detach();
}
}
public class Label extends WebComponent {
private IModel model;
public Label(IModel model) {
add(new ModelBehavior(this.model = model));
}
}
Detachment will then be automatic.
Sven
Igor Vaynberg schrieb:
you still have ondetach()...but for convinience we can automatically
detach any imodel fields, i actually wanted to do this for a while...
-igor
On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner [EMAIL PROTECTED] wrote:
and if i store it in metadata ;)
On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
why even have an interface? just detach all imodel fields via reflection!
-igor
On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED]
wrote:
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
it all depends, on how and what you're developing.
Yeah. I actually use less and less models in the regular way nowadays.
I use plenty of panels (the app I work on hardly uses separate pages)
that nest other panels in them (typically detail views or dialogs)
that reuse models of the parent. But indeed YMMV.
Personally, I think the whole generics business exposes that the
one-one relation between components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor, but as generics aren't as 'optional' it is all very in
your face suddenly.
I think on the longer term (post 1.4) we should re-think how models
work in Wicket. See if we can find an elegant way to make this more
flexible (I'm not in favor of the id based thing someone posted
earlier btw) without breaking the whole world.
We discussed this on ##wicket yesterday. I asked why we have models
on all components and someone pointed out that the main reason was
about the detach stuff I believe. But, couldn't that be solved by
having some components that implement something like IModelDriven (or
IModelBacked or whatever) and the detach logic could apply to only
those components? Also, someone has pointed out that when they create
their own components, they sometimes (such as in Palette) have
multiple models that they deal with. Allowing components to name
their models what they want would be nice, too.
FWIW, I'm still on the fence when it comes to whether we should go for
a full or partial (models only) implementation of generics, though I'm
leaning towards partial.
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]
-
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
like i said, i dont mind removing the default slot if we add nice automatic detachment for fields. -igor On Wed, Jun 4, 2008 at 12:23 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 11:48 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: i dont think it exposes anything, or that anything is flawed. the component provides a slot for a default model - it is there totally out of convinience. i think what is flawed here is that we tied the two types via generics. It depends on how you phrase things. It is a fact that currently models and components are tightly bound because of 'getModelObject'. The main issue is that with 1.3 you can simply omit the model, whereas with generified components the choice to not use a model is explicit (whether you use void, or an annotation to ignore warnings). Very annoying if you ask me, and it triggered me to think that this is another hint that the one-one relationship between components and models like we have now is somewhat flawed. I'm not saying it totally stinks and that we should get rid of it tomorrow, just that it is something we might rethink. You know I'm a fan of rethinking stuff ;-) 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
yuck! :)
-igor
On Wed, Jun 4, 2008 at 2:29 PM, Sven Meier [EMAIL PROTECTED] wrote:
A component could add a behavior for each model it wants to use:
public class ModelBehavior extends AbstractBehavior {
private IModel model;
public ModelBehavior(IModel model) {
this.model = model;
}
public void detach(Component component) {
this.model.detach();
}
}
public class Label extends WebComponent {
private IModel model;
public Label(IModel model) {
add(new ModelBehavior(this.model = model));
}
}
Detachment will then be automatic.
Sven
Igor Vaynberg schrieb:
you still have ondetach()...but for convinience we can automatically
detach any imodel fields, i actually wanted to do this for a while...
-igor
On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner [EMAIL PROTECTED]
wrote:
and if i store it in metadata ;)
On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg [EMAIL PROTECTED]
wrote:
why even have an interface? just detach all imodel fields via
reflection!
-igor
On Wed, Jun 4, 2008 at 3:37 AM, James Carman
[EMAIL PROTECTED]
wrote:
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
it all depends, on how and what you're developing.
Yeah. I actually use less and less models in the regular way nowadays.
I use plenty of panels (the app I work on hardly uses separate pages)
that nest other panels in them (typically detail views or dialogs)
that reuse models of the parent. But indeed YMMV.
Personally, I think the whole generics business exposes that the
one-one relation between components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor, but as generics aren't as 'optional' it is all very in
your face suddenly.
I think on the longer term (post 1.4) we should re-think how models
work in Wicket. See if we can find an elegant way to make this more
flexible (I'm not in favor of the id based thing someone posted
earlier btw) without breaking the whole world.
We discussed this on ##wicket yesterday. I asked why we have models
on all components and someone pointed out that the main reason was
about the detach stuff I believe. But, couldn't that be solved by
having some components that implement something like IModelDriven (or
IModelBacked or whatever) and the detach logic could apply to only
those components? Also, someone has pointed out that when they create
their own components, they sometimes (such as in Palette) have
multiple models that they deal with. Allowing components to name
their models what they want would be nice, too.
FWIW, I'm still on the fence when it comes to whether we should go for
a full or partial (models only) implementation of generics, though I'm
leaning towards partial.
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]
-
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
If only... if only
we had this construct:
class ComponentT default Void
{
}
then all our problems with verbosity would be gone..
TextField tf = new TextField(id) // just default Void
Also only declare it once:
TextFieldStirng tf = new TextField(id);
And both ways type guessing, so
TextFieldString tf = new TextField(id, new Model()); //textfield and
model are both just String
or
TextField tf = new TextField(id, new ModelString()); // text field gets
the type of its given model..
I guess we should make a feature request for sun and then Vote on it with
all of us!
(and make noise on the internet...)
johan
On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila [EMAIL PROTECTED]
wrote:
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)
Agreed.
+1 for NOT generifying everything, because most components are set it
and forget it = generifying everything is unnecessary clutter.
I will continue to use Wicket whatever is decided, though :)
-Marcus
-
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
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) Agreed. +1 for NOT generifying everything, because most components are set it and forget it = generifying everything is unnecessary clutter. I will continue to use Wicket whatever is decided, though :) -Marcus - 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. I didn't read all of the posts here, but I would suggest to go for Component or even @SuppressWarnings(unchecked). This way, you don't have to use generified components but are still able to do so. Currently, I am always passing models as parameter to the constructor of my custom components. Those parameters are always named according to the expected type they contain (e.g. fooModel if i expect an object of type Foo in there). Therefore, generics could jump in quite easily and I am looking forward to use them! - --- Stefan Fußenegger http://talk-on-tech.blogspot.com // looking for a nicer domain ;) -- 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-tp17589984p17618096.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
Johan Compagner 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. Ok, maybe we have to be more precise and maybe the term generified is not. Following this: http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.2 I'd still say: class A_HomePage extends WebPage and class B_HomePage extends WebPageVoid are both classes that are not generic as they don't declare a type variable. 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 I read: Class? extends Page? as: the method returns a parametrized class object, where the type parameter is a non generic type extending the generic type Page. Though I have no prove on this. What would happen if we did: public abstract Class? extends Page and have a supresswarning in our code. I'd say its worth a try, but also I'd take the need for the supresswarning as a strong signal for keeping components non-generic alltogether. 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
[x] Can best be done in a limited fashion, where we only generify IModel but not components. [x] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. I basically agree to what Igor says on this issue. - -- Kent Tong Wicket tutorials freely available at http://www.agileskills2.org/EWDW Axis2 tutorials freely available at http://www.agileskills2.org/DWSAA -- 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-tp17589984p17618364.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
In java 1.7 it will allow: TextFieldStirng tf = new TextField(id);
So, at least one of your wishes will come true ;o)
I like the default idea.
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 4:15 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
If only... if only
we had this construct:
class ComponentT default Void
{
}
then all our problems with verbosity would be gone..
TextField tf = new TextField(id) // just default Void
Also only declare it once:
TextFieldStirng tf = new TextField(id);
And both ways type guessing, so
TextFieldString tf = new TextField(id, new Model()); //textfield and
model are both just String or TextField tf = new TextField(id, new
ModelString()); // text field gets the type of its given model..
I guess we should make a feature request for sun and then Vote on it
with all of us!
(and make noise on the internet...)
johan
On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila
[EMAIL PROTECTED]
wrote:
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)
Agreed.
+1 for NOT generifying everything, because most components are set it
and forget it = generifying everything is unnecessary clutter.
I will continue to use Wicket whatever is decided, though :)
-Marcus
-
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, We haven't worked with 1.4 enough to form an opinion, but we'll definitely upgrade to it for the next project. On 6/3/08, Johan Compagner [EMAIL PROTECTED] wrote: If only... if only we had this construct: class ComponentT default Void If only we had type inference :-) Is this any nicer in scala? Gabor Szokoli - 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 only we had type inference :-) Is this any nicer in scala? in scala you wouldn't have to have the getModel/getModelObject within Component in the first place (you could use mixins for this purpose). --- 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
Gabor Szokoli wrote: Hi, We haven't worked with 1.4 enough to form an opinion, but we'll definitely upgrade to it for the next project. On 6/3/08, Johan Compagner [EMAIL PROTECTED] wrote: If only... if only we had this construct: class ComponentT default Void If only we had type inference :-) Is this any nicer in scala? Gabor Szokoli I haven't used 1.4 either, but I've been following the discussion and from my experience with 1.3 I'd say that generifying models is definately a good idea. +1 for that I'm not so sure about generifying the components though. I think the benefit would not be that great and it may very well be more trouble than it's worth - especially when writing/extending components for your own needs. Edmund -- Liland ...does IT better Liland IT GmbH Software Architekt email: [EMAIL PROTECTED] office: +43 (0)463 220-111 | fax: +43 (0)463 220-288 http://www.Liland.at - 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 6/3/08, Jan Kriesten [EMAIL PROTECTED] wrote: If only we had type inference :-) Is this any nicer in scala? in scala you wouldn't have to have the getModel/getModelObject within Component in the first place (you could use mixins for this purpose). I was thinking about using the existing wicket 1.4 API from scala, if that's any more comfortable. Gabor Szokoli - 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
really?
i still cant find information what will really be 1.7..
On Tue, Jun 3, 2008 at 1:29 PM, Hoover, William [EMAIL PROTECTED] wrote:
In java 1.7 it will allow: TextFieldStirng tf = new TextField(id);
So, at least one of your wishes will come true ;o)
I like the default idea.
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 4:15 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
If only... if only
we had this construct:
class ComponentT default Void
{
}
then all our problems with verbosity would be gone..
TextField tf = new TextField(id) // just default Void
Also only declare it once:
TextFieldStirng tf = new TextField(id);
And both ways type guessing, so
TextFieldString tf = new TextField(id, new Model()); //textfield and
model are both just String or TextField tf = new TextField(id, new
ModelString()); // text field gets the type of its given model..
I guess we should make a feature request for sun and then Vote on it
with all of us!
(and make noise on the internet...)
johan
On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila
[EMAIL PROTECTED]
wrote:
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)
Agreed.
+1 for NOT generifying everything, because most components are set it
and forget it = generifying everything is unnecessary clutter.
I will continue to use Wicket whatever is decided, though :)
-Marcus
-
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
Type inference alone will not really help us To kill the verbosity on components that are not used with models we need something like T default Void johan On Tue, Jun 3, 2008 at 1:34 PM, Gabor Szokoli [EMAIL PROTECTED] wrote: Hi, We haven't worked with 1.4 enough to form an opinion, but we'll definitely upgrade to it for the next project. On 6/3/08, Johan Compagner [EMAIL PROTECTED] wrote: If only... if only we had this construct: class ComponentT default Void If only we had type inference :-) Is this any nicer in scala? Gabor Szokoli - 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:46 AM, Jan Kriesten [EMAIL PROTECTED] wrote: Hi Gabor, I was thinking about using the existing wicket 1.4 API from scala, if that's any more comfortable. I tried to migrate a bigger project from 1.3 to 1.4 api - and it isn't really more comfortable. It's easier to do one or two casts than trying to conform the generics Component structure. Especially since there are cases with 1.4 generics (like StringResourceModel) which sometimes aren't recognized as IModelString (which of course is more a Scala than a Wicket problem)... Remember that 1.4 isn't done yet either. Perhaps these are just growing pains that the wicket team is going through (or perhaps it's not). We should outline these pain points and let the team know about them (and perhaps a proposed solution), so that they have an opportunity to address them. - 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 Gabor, I was thinking about using the existing wicket 1.4 API from scala, if that's any more comfortable. I tried to migrate a bigger project from 1.3 to 1.4 api - and it isn't really more comfortable. It's easier to do one or two casts than trying to conform the generics Component structure. Especially since there are cases with 1.4 generics (like StringResourceModel) which sometimes aren't recognized as IModelString (which of course is more a Scala than a Wicket problem)... 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
Look in the section Laguage Proposals Shorter Instance Creations
in:
http://blogs.sun.com/dannycoward/resource/Java7Overview_Prague_JUG.pdf
Other useful links:
http://blogs.sun.com/ahe/resource/java-se-7-EclipseCon-2007.pdf
http://puredanger.com/techfiles/java7.pdf
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 7:47 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
really?
i still cant find information what will really be 1.7..
On Tue, Jun 3, 2008 at 1:29 PM, Hoover, William [EMAIL PROTECTED]
wrote:
In java 1.7 it will allow: TextFieldStirng tf = new TextField(id);
So, at least one of your wishes will come true ;o)
I like the default idea.
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 03, 2008 4:15 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
If only... if only
we had this construct:
class ComponentT default Void
{
}
then all our problems with verbosity would be gone..
TextField tf = new TextField(id) // just default Void
Also only declare it once:
TextFieldStirng tf = new TextField(id);
And both ways type guessing, so
TextFieldString tf = new TextField(id, new Model()); //textfield
and model are both just String or TextField tf = new TextField(id,
new ModelString()); // text field gets the type of its given model..
I guess we should make a feature request for sun and then Vote on it
with all of us!
(and make noise on the internet...)
johan
On Tue, Jun 3, 2008 at 8:58 AM, Marcus Mattila
[EMAIL PROTECTED]
wrote:
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)
Agreed.
+1 for NOT generifying everything, because most components are set
+it
and forget it = generifying everything is unnecessary clutter.
I will continue to use Wicket whatever is decided, though :)
-Marcus
- 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 James, Remember that 1.4 isn't done yet either. Perhaps these are just growing pains that the wicket team is going through (or perhaps it's not). it's not... ;-) No, really, I have invested quite some time to get comfortable with Components + Generics. And I came to the conclusion: it's not worth it. 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
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 generifying component adds too much verbosity, considering a lot of components don't even have a model. - 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 one of adopters laterst release and I invested much time for upgrading all our projects to 1.4M2 . I think, that generification of Wicket has many positive impacts, but also some negative impact on simplicity and ease of use. I don't see too many advantages of fully typed components - the biggest win for me, is that I directly see, what I have or what should be in the model. I think, this is not worth the other problems. Living with generics is a little bit harder, than living with no generics. But I personally have no problem to live with it. If I should say decision, based on my experience: --- I think, that generification of Wicket involves a little bit more negative, than positive effects, so - give it away. We loose som benefits, but many other things, will be simpler. Stefan Simik -- 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-tp17589984p17625678.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
Eelco Hillenius wrote: 1) Generifying* Wicket [x] Can best be done like currently in the 1.4 branch, where models [x] Can best be done in a limited fashion, where we only generify Both are acceptable to me 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 Not sure about definitely, but if IModel isn't generified I'll evaluate other frameworks for my next project. /Anders - 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. 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. ryan - 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 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. We are on 1.4 trunk on a huge project ( 100k LOC) which we are still in the middle of converting as we started out on 1.3.x. I can say without a doubt that generic components do get in the way, and that there are only a few cases where we actually call getModelObject(), for which casting is an acceptable workaround. I would go so far as saying, the concept of 1:1 Model:Component can be misleading. As a number of previous posters have indicated, and I can validate first-hand, most components are not model backed. In my case, and I even have a few components that are backed by more than one model. So another angle to consider is completely decoupling Model from Component. Instead you might have setModel(String id, IModel?) and getModel(String id)... The old getModel() would be the equivalent of calling getModel((String)null)... I understand that this is a huge API break, with marginal value, but it does express the Model:Component relationship a lot more clearly. -- 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-tp17589984p17628984.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
[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]
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. [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 find anon inner classes can benefit a lot from generics. - This means both imodel and component - but I think both are an improvement over not having generics. 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 is a breath of fresh air - with or without generics. Just more fresh air with ;). ** It needs 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-tp17589984p17637897.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
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 the last two years was that any project that was adopted to generics had much less errors afterwards. But the main problem in this discussion seems to be that there are two very different sorts of Web Applications that are developed with wicket and both may have predecessors that are non generic. Type A: A Web applicatons that make heavy use of Models, like classic desktop allications that are ported to the web. I think the programmers of such applications like Generics becaus they help them to avoid erros and the current wicket generic implementation leads to a strong typed application that needs a good object model (and a good database design). If you port an exisitng wicket application with no generic to wicket 1.4 you might discover some unclear object model problems in your exisitng code. And it's always easier to point to wicket's generics than to blame your own code :-) Type B: A Web Application with more static content, only some date (like user logins, user profile data). In this case it's clear that some people say why should I always tyle 'LinkVoid', none of my links has a Model, just about 10% of my Components have a Model. But why dont't they write their own wrapper e.g. MyVoidLink extends LinkVoid? I remember a dicsusson about such Components some weeks ago.
RE: users, please give us your opinion: what is your take on generics with Wicket
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]
RE: users, please give us your opinion: what is your take on generics with Wicket
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 the last two years was that any project that was adopted to generics had much less errors afterwards. But the main problem in this discussion seems to be that there are two very different sorts of Web Applications that are
