Re: users, please give us your opinion: what is your take on generics with Wicket

2008-08-13 Thread ronaldtm

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

2008-08-03 Thread John Patterson

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

2008-07-28 Thread Ricky
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

2008-07-25 Thread jpswain

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

2008-07-20 Thread Andras Hatvani

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

2008-06-18 Thread Ari M

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

2008-06-17 Thread Taranenko

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

2008-06-12 Thread Jon Laidler



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

2008-06-11 Thread Philip A. Chapman
-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

2008-06-09 Thread Daniel Walmsley

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

2008-06-09 Thread Peter Ertl


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

2008-06-09 Thread Stefan Lindner
 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

2008-06-07 Thread Ivo van Dongen




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

2008-06-07 Thread xiefei




 [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

2008-06-05 Thread dvd
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]



AW: users, please give us your opinion: what is your take on generics with Wicket

2008-06-05 Thread Stefan Lindner
[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.

This may be an option for small projects or for personal use. But for
big projects for software sold all around the world this is not a good
design. Each error(type mismatch) that can be avoided during development
costs
- less time in quality assurance
- debugging
- maintaining and update releases
And: less money in development at all.

So Generics are not only a nice thing wicket adopts as Java 5 hhas
Generics. It helps us to develop faster and cheaper and to increase the
quality of our software.

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

2008-06-05 Thread Johan Compagner
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

2008-06-05 Thread Igor Vaynberg
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

2008-06-05 Thread pkcinna

   [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

2008-06-05 Thread Johan Compagner
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

2008-06-05 Thread James Carman
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

2008-06-05 Thread Igor Vaynberg
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

2008-06-05 Thread James Carman
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

2008-06-05 Thread Eelco Hillenius
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

2008-06-05 Thread Eelco Hillenius
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

2008-06-05 Thread James Carman
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

2008-06-05 Thread Eelco Hillenius
 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

2008-06-05 Thread Johan Compagner
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

2008-06-05 Thread Stefan Lindner
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

2008-06-05 Thread Tsutomu Yano

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

2008-06-04 Thread Eelco Hillenius
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

2008-06-04 Thread Igor Vaynberg
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

2008-06-04 Thread Jan Kriesten




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

2008-06-04 Thread Stefan Lindner
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

2008-06-04 Thread Eelco Hillenius
 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

2008-06-04 Thread Johan Compagner
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

2008-06-04 Thread James Carman
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

2008-06-04 Thread Matej Knopp
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

2008-06-04 Thread Johan Compagner
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

2008-06-04 Thread Matej Knopp
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

2008-06-04 Thread Jan Kriesten


hi johan,


and remove getModel/getModelObject methods from component itself?
But then everybody that does use models have to implement it..


that would be the consequence with it's tradeoff.

i wouldn't have a problem with that though:

val myLabel = new Label('id') with StringModel( :-P )

but i suppose the java lobby will complain... ;-)

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

2008-06-04 Thread Igor Vaynberg
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

2008-06-04 Thread Johan Compagner
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

2008-06-04 Thread John Patterson



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

2008-06-04 Thread Igor Vaynberg
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

2008-06-04 Thread Eelco Hillenius
 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

2008-06-04 Thread Matej Knopp
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

2008-06-04 Thread Eelco Hillenius
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

2008-06-04 Thread Eelco Hillenius
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

2008-06-04 Thread Martijn Dashorst
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

2008-06-04 Thread Eelco Hillenius
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

2008-06-04 Thread Igor Vaynberg
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

2008-06-04 Thread Johan Compagner
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

2008-06-04 Thread Eelco Hillenius
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

2008-06-04 Thread Igor Vaynberg
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

2008-06-04 Thread Patrick Angeles


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

2008-06-04 Thread Matej Knopp
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

2008-06-04 Thread Brill Pappin
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

2008-06-04 Thread Brill Pappin
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

2008-06-04 Thread Brill Pappin
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

2008-06-04 Thread Brill Pappin
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

2008-06-04 Thread Brill Pappin
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

2008-06-04 Thread Brill Pappin
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

2008-06-04 Thread Igor Vaynberg
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

2008-06-04 Thread Eelco Hillenius
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

2008-06-04 Thread Daniel Frisk
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

2008-06-04 Thread Eelco Hillenius
 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

2008-06-04 Thread Eelco Hillenius
 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

2008-06-04 Thread Eelco Hillenius
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

2008-06-04 Thread Daniel Frisk
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

2008-06-04 Thread Eelco Hillenius
 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

2008-06-04 Thread Johan Compagner
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

2008-06-04 Thread Roland Huss


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

2008-06-04 Thread Sven Meier

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

2008-06-04 Thread Igor Vaynberg
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

2008-06-04 Thread Igor Vaynberg
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

2008-06-03 Thread Johan Compagner
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

2008-06-03 Thread Marcus Mattila
 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

2008-06-03 Thread Stefan Fußenegger

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

2008-06-03 Thread Martin Funk

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

2008-06-03 Thread Kent Tong

   [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

2008-06-03 Thread Hoover, William
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

2008-06-03 Thread Gabor Szokoli
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

2008-06-03 Thread Jan Kriesten



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

2008-06-03 Thread Edmund Urbani

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

2008-06-03 Thread Gabor Szokoli
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

2008-06-03 Thread Johan Compagner
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

2008-06-03 Thread Johan Compagner
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

2008-06-03 Thread James Carman
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

2008-06-03 Thread Jan Kriesten


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

2008-06-03 Thread Hoover, William
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

2008-06-03 Thread Jan Kriesten


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

2008-06-03 Thread Jonas
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

2008-06-03 Thread Stefan Simik

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

2008-06-03 Thread Anders Peterson

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

2008-06-03 Thread Ryan McKinley


  [ 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

2008-06-03 Thread Patrick Angeles


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

2008-06-03 Thread Mike Comb

  [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

2008-06-03 Thread Ned Collyer

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

2008-06-03 Thread Brill Pappin
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.


 What do you think about it? Would it help users of Type B to have 
 VoidComponents?

 Stefan

 

  1   2   3   >