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

[Wouter De Vaal]

> 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: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Antoine van Wel]

> 1) Generifying* Wicket
>   [X] Can best be done like currently in the 1.4 branch, where models
> and components are both generified. I care most about the improved
> static type checking generified models and components give Wicket.

This is the only solution that makes sense, the other options are
either a partial solution (which is a *very, very* bad thing, mixing
generic with non-generic code INSIDE a framework!?!?) or no solution
at all (which has my preference over a partial solution, since at
least it is concise).


> 2) How strongly do you feel about your choice above?
>   [X] I might rethink upgrading if my choice doesn't win.

Seriously, no generics at all is better than a partial solution. Since
upgrading involves more issues than generics alone, I may rethink
only... If the decision to upgrade boils down to this issue, then I
won't.


Antoine

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Gwyn]

On Mon, Jun 2, 2008 at 8:17 AM, Scott Swank <scott.swank@...> wrote:
> I would prefer to have models and components generified, however if
> this makes the API too verbose or cumbersome to use then I prefer to
> fall back to only generified models.  At one point someone suggested a
> wiki page outlining the difficulties with generics, does such a page
> exist?

http://cwiki.apache.org/WICKET/generics.html

/Gwyn

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Guðmundur Bjarni]

I agree with Antoine.

Guðmundur Bjarni

Antoine van Wel wrote:

> 1) Generifying* Wicket
>   [X] Can best be done like currently in the 1.4 branch, where models
> and components are both generified. I care most about the improved
> static type checking generified models and components give Wicket.

This is the only solution that makes sense, the other options are
either a partial solution (which is a *very, very* bad thing, mixing
generic with non-generic code INSIDE a framework!?!?) or no solution
at all (which has my preference over a partial solution, since at
least it is concise).


> 2) How strongly do you feel about your choice above?
>   [X] I might rethink upgrading if my choice doesn't win.

Seriously, no generics at all is better than a partial solution. Since
upgrading involves more issues than generics alone, I may rethink
only... If the decision to upgrade boils down to this issue, then I
won't.

[Nino.Martinez]

> 1) Generifying* Wicket
>    [x] Can best be done like currently in the 1.4 branch, where models
> and components are both generified. I care most about the improved
> static type checking generified models and components give Wicket.
>
> 2) How strongly do you feel about your choice above?
>    [x] Whatever choice ultimately made, I'll happily convert/ start
> using 1.4 and up.
>  


Wicket for love

Nino Martinez Wael
Java Specialist @ Jayway DK
http://www.jayway.dk
[phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[whoover]

1) Generifying* Wicket
   [X] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.
        Verbose VS Clarity, Clarity wins hands down.

2) How strongly do you feel about your choice above?
   [X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.


-----Original Message-----
From: Eelco Hillenius [mailto:eelco.hillenius@...]
Sent: Sunday, June 01, 2008 4:45 PM
To: wicket user list
Subject: users, please give us your opinion: what is your take on
generics with Wicket

Hi all,

We have had several threads in this and the dev list, and some
discussions in the public on how to incorporate generics in Wicket.

I'd like to use this thread to gather the opinions of as many regular
Wicket users as we can. Please help us get an impression of what our
users think about the issue by completing this simple survey. Note that
it is not a vote; we only want to get an idea of what you think.

1) Generifying* Wicket
   [ ] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.
   [ ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do for
API clarity (declaring a component to only accept certain models for
instance) than static type checking.
   [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill
in your opinion here).
   [ ] .... (anything other than these choices?)

2) How strongly do you feel about your choice above?
   [ ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
   [ ] I might rethink upgrading if my choice doesn't win.
   [ ] I definitively won't be using 1.4. if Wicket doesn't go for my
preference.

Thanks in advance for everyone participating, and pls feel free to
explain yourself further beyond just answering these questions!

Eelco

p.s. I suggest that the core devs and most active participants and
previous discussions wait a few days before giving their opinions so
that we don't flood the thread right from the start.

* Parameterizing would probably be the better word to use, but
generifying seems to be the word that many people use.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Wouter Huijnink]

> 1) Generifying* Wicket
>    [X ] Can best be done in a limited fashion, where we only generify
> IModel but not components. I care more about what generifying can do
> for API clarity (declaring a component to only accept certain models
> for instance) than static type checking.
>
> 2) How strongly do you feel about your choice above?
>    [X ] I might rethink upgrading if my choice doesn't win.
>  

We do almost all our frontend stuff with Wicket. Our developers think
that the full generification will have a significant impact on ease of
use and speed of development, whereas they don't see the advantages of
fully typed components.

regards,
Wouter

--
Wouter Huijnink
Func. Internet Integration
W http://www.func.nl
T [phone]
F [phone]


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Alex Jacoby-2]

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 haven't tried migrating to 1.4 yet (waiting for the dust to settle),  
so I don't have any first-hand experience.

The last java posse podcast discussed the wicket generics problem at  
length (though without any direct knowledge of the issues).  They  
recommended a book for designing generified APIs, but the title  
escapes me.  Here's the podcast link:
http://media.libsyn.com/media/dickwall/JavaPosse189.mp3
I don't mean to imply that the core devs haven't already mastered all  
there is to master about generics, but everyone seems to agree that  
they can be tricky little beasts.  I don't mind waiting longer for 1.4  
if that's what it takes.

Alex

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[richardwilko]

   [ x ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
 
   [ x ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.

To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string.  It would also be nice if the .add() and others methods on components could return the type of component it is rather than just a Component object.  eg you cant do 'new TextArea(...).add(some behavior).setRequired(true) because the add behaviour method returns a Component not a TextArea and setRequired is not available on Components.
 
Thanks

[Craig McIlwee ()]

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.

Any use of generics is better than versions < 1.4 using no generics

EDIT: after finally getting a chance to user 1.4 over the last couple of days, i'm changing my vote to full out generification

[Johan Compagner]

why are you contradicting yourself?

"To be honest I don't see the advantage of generic components, all I want is
to not have to do casting when I'm using models, .getModelObject() should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string."

if you have just IModel then you will have to cast.. getModelObject will
always return just Object then.


about:

"new TextArea(...).add(some behavior).setRequired(true) "

this can be done but then we have to override some methods of component and
then return another type
The problem is that this could result in us lifting a final where we dont
want to..
But this is outside the scope of generics

johan

On Mon, Jun 2, 2008 at 3:26 PM, richardwilko <richardjohnwilkinson@...>
wrote:

>
>
>   [ x ] Can best be done in a limited fashion, where we only generify
> IModel but not components. I care more about what generifying can do
> for API clarity (declaring a component to only accept certain models
> for instance) than static type checking.
>
>    [ x ] Whatever choice ultimately made, I'll happily convert/ start
> using 1.4 and up.
>
> To be honest I don't see the advantage of generic components, all I want is
> to not have to do casting when I'm using models, .getModelObject() should
> return the type that I put in, in a list view, if I give it a list of
> strings I dont want to cast the listItem model object to a string.  It
> would
> also be nice if the .add() and others methods on components could return
> the
> type of component it is rather than just a Component object.  eg you cant
> do
> 'new TextArea(...).add(some behavior).setRequired(true) because the add
> behaviour method returns a Component not a TextArea and setRequired is not
> available on Components.
>
> Thanks
> --
> View this message in context:
> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[mozvip]

1) Generifying* Wicket
   [X] Should be avoided, definitly. All this generics stuff is ruining my wicket experience.

2) How strongly do you feel about your choice above?
   [X] I might rethink upgrading if my choice doesn't win.

[mozvip]

1) Generifying* Wicket
   [X] Should be avoided, definitly. All this generics stuff is ruining my wicket experience.

2) How strongly do you feel about your choice above?
   [X] I might rethink upgrading if my choice doesn't win.

[richardwilko]

ok maybe i misread this :

'Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.'

but those 2 sentences seem to contradict each other, the first says only generify IModel which I assumed ti mean that when you put a String into a model you would get a String out of it, the second seems to says generifiying components to make them only accept some model types.

So just to clarify my position

generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form)
{
        EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject();
        ....
is what I would like to see.

generic components im not bothered about.

if using generics wont do away with the casting then I dont see any point to using them at all.

Johan Compagner wrote:

why are you contradicting yourself?

"To be honest I don't see the advantage of generic components, all I want is
to not have to do casting when I'm using models, .getModelObject() should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string."

if you have just IModel then you will have to cast.. getModelObject will
always return just Object then.


ok maybe i misread

about:

"new TextArea(...).add(some behavior).setRequired(true) "

this can be done but then we have to override some methods of component and
then return another type
The problem is that this could result in us lifting a final where we dont
want to..
But this is outside the scope of generics

johan

On Mon, Jun 2, 2008 at 3:26 PM, richardwilko <[e-mail]>
wrote:

>
>
>   [ x ] Can best be done in a limited fashion, where we only generify
> IModel but not components. I care more about what generifying can do
> for API clarity (declaring a component to only accept certain models
> for instance) than static type checking.
>
>    [ x ] Whatever choice ultimately made, I'll happily convert/ start
> using 1.4 and up.
>
> To be honest I don't see the advantage of generic components, all I want is
> to not have to do casting when I'm using models, .getModelObject() should
> return the type that I put in, in a list view, if I give it a list of
> strings I dont want to cast the listItem model object to a string.  It
> would
> also be nice if the .add() and others methods on components could return
> the
> type of component it is rather than just a Component object.  eg you cant
> do
> 'new TextArea(...).add(some behavior).setRequired(true) because the add
> behaviour method returns a Component not a TextArea and setRequired is not
> available on Components.
>
> Thanks
> --
> View this message in context:
> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [e-mail]
> For additional commands, e-mail: [e-mail]
>
>

[Stefan Lindner]

1) Generifying* Wicket
   [x] Can best be done like currently in the 1.4 branch, where models
and components are both generified. I care most about the improved
static type checking generified models and components give Wicket.


2) How strongly do you feel about your choice above?
   [x] I definitively won't be using 1.4. if Wicket doesn't go for my
preference.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[whoover]

Goes to show you that people have a tendency to reject things that they
do not understand rather than put in the effort :o)

-----Original Message-----
From: richardwilko [mailto:richardjohnwilkinson@...]
Sent: Monday, June 02, 2008 10:21 AM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket


ok maybe i misread this :

'Can best be done in a limited fashion, where we only generify IModel
but not components. I care more about what generifying can do for API
clarity (declaring a component to only accept certain models for
instance) than static type checking.'

but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into
a model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.

So just to clarify my position

generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form) {
        EmailFormModel emailFormModel = (EmailFormModel)
form.getModelObject();
        ....
is what I would like to see.

generic components im not bothered about.

if using generics wont do away with the casting then I dont see any
point to using them at all.



Johan Compagner wrote:

>
> why are you contradicting yourself?
>
> "To be honest I don't see the advantage of generic components, all I
> want is to not have to do casting when I'm using models,
> .getModelObject() should return the type that I put in, in a list
> view, if I give it a list of strings I dont want to cast the listItem
> model object to a string."
>
> if you have just IModel then you will have to cast.. getModelObject
> will always return just Object then.
>
>
> ok maybe i misread
>
> about:
>
> "new TextArea(...).add(some behavior).setRequired(true) "
>
> this can be done but then we have to override some methods of
> component and then return another type The problem is that this could
> result in us lifting a final where we dont want to..
> But this is outside the scope of generics
>
> johan
>
> On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
> <richardjohnwilkinson@...>
> wrote:
>
>>
>>
>>   [ x ] Can best be done in a limited fashion, where we only generify

>> IModel but not components. I care more about what generifying can do
>> for API clarity (declaring a component to only accept certain models
>> for instance) than static type checking.
>>
>>    [ x ] Whatever choice ultimately made, I'll happily convert/ start

>> using 1.4 and up.
>>
>> To be honest I don't see the advantage of generic components, all I
>> want is to not have to do casting when I'm using models,
>> .getModelObject() should return the type that I put in, in a list
>> view, if I give it a list of strings I dont want to cast the listItem

>> model object to a string.  It would also be nice if the .add() and
>> others methods on components could return the type of component it is

>> rather than just a Component object.  eg you cant do 'new
>> TextArea(...).add(some behavior).setRequired(true) because the add
>> behaviour method returns a Component not a TextArea and setRequired
>> is not available on Components.
>>
>> Thanks
>> --
>> View this message in context:
>> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is
>> -your-take-on-generics-with-Wicket-tp17589984p17601296.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>
>

--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17602507.html
Sent from the Wicket - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[jwcarman]

On Mon, Jun 2, 2008 at 10:21 AM, richardwilko
<richardjohnwilkinson@...> wrote:

>
> ok maybe i misread this :
>
> 'Can best be done in a limited fashion, where we only generify
> IModel but not components. I care more about what generifying can do
> for API clarity (declaring a component to only accept certain models
> for instance) than static type checking.'
>
> but those 2 sentences seem to contradict each other, the first says only
> generify IModel which I assumed ti mean that when you put a String into a
> model you would get a String out of it, the second seems to says
> generifiying components to make them only accept some model types.
>
> So just to clarify my position
>
> generic models which would do away with this type of casting:
> protected void onSubmit(AjaxRequestTarget target, Form form)
> {
>        EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject();
>        ....
> is what I would like to see.
>
> generic components im not bothered about.
>

Using generics will do away with the casting, but only if you
genericize Component.  Merely genericizing IModel won't get rid of the
casting by itself.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Johan Compagner]

Ok you example doesnt work..
You will need to cast there

Then IModel only only helps describing the constructor. After that you loose
the generics or you have to ofcourse keep the models and dont work anymore
directly with the components

So if we only do IModel and not component
then this will need casting or supresswarnings:

TextField tf = new TextField("id", new Model<Stirng>(myString));

tf.getModelObject() will return Object you need to cast to String.
tf.getModel() will return IModel<?> so you need to cast it and supress
warnings and that kind of stuff.

So to keep the type safety you have to do this:


Model<String> model = new Model<Stirng>(myString);
TextField tf = new TextField("id",model );

model.getObject() this will return a String..

johan


On Mon, Jun 2, 2008 at 4:21 PM, richardwilko <richardjohnwilkinson@...>
wrote:

>
> ok maybe i misread this :
>
> 'Can best be done in a limited fashion, where we only generify
> IModel but not components. I care more about what generifying can do
> for API clarity (declaring a component to only accept certain models
> for instance) than static type checking.'
>
> but those 2 sentences seem to contradict each other, the first says only
> generify IModel which I assumed ti mean that when you put a String into a
> model you would get a String out of it, the second seems to says
> generifiying components to make them only accept some model types.
>
> So just to clarify my position
>
> generic models which would do away with this type of casting:
> protected void onSubmit(AjaxRequestTarget target, Form form)
> {
>        EmailFormModel emailFormModel = (EmailFormModel)
> form.getModelObject();
>        ....
> is what I would like to see.
>
> generic components im not bothered about.
>
> if using generics wont do away with the casting then I dont see any point
> to
> using them at all.
>
>
>
> Johan Compagner wrote:
> >
> > why are you contradicting yourself?
> >
> > "To be honest I don't see the advantage of generic components, all I want
> > is
> > to not have to do casting when I'm using models, .getModelObject() should
> > return the type that I put in, in a list view, if I give it a list of
> > strings I dont want to cast the listItem model object to a string."
> >
> > if you have just IModel then you will have to cast.. getModelObject will
> > always return just Object then.
> >
> >
> > ok maybe i misread
> >
> > about:
> >
> > "new TextArea(...).add(some behavior).setRequired(true) "
> >
> > this can be done but then we have to override some methods of component
> > and
> > then return another type
> > The problem is that this could result in us lifting a final where we dont
> > want to..
> > But this is outside the scope of generics
> >
> > johan
> >
> > On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
> > <richardjohnwilkinson@...>
> > wrote:
> >
> >>
> >>
> >>   [ x ] Can best be done in a limited fashion, where we only generify
> >> IModel but not components. I care more about what generifying can do
> >> for API clarity (declaring a component to only accept certain models
> >> for instance) than static type checking.
> >>
> >>    [ x ] Whatever choice ultimately made, I'll happily convert/ start
> >> using 1.4 and up.
> >>
> >> To be honest I don't see the advantage of generic components, all I want
> >> is
> >> to not have to do casting when I'm using models, .getModelObject()
> should
> >> return the type that I put in, in a list view, if I give it a list of
> >> strings I dont want to cast the listItem model object to a string.  It
> >> would
> >> also be nice if the .add() and others methods on components could return
> >> the
> >> type of component it is rather than just a Component object.  eg you
> cant
> >> do
> >> 'new TextArea(...).add(some behavior).setRequired(true) because the add
> >> behaviour method returns a Component not a TextArea and setRequired is
> >> not
> >> available on Components.
> >>
> >> Thanks
> >> --
> >> View this message in context:
> >>
> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602507.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Johan Compagner]

yes thats why i am against Referendums (politically) :)

On Mon, Jun 2, 2008 at 4:27 PM, Hoover, William <whoover@...> wrote:

> Goes to show you that people have a tendency to reject things that they
> do not understand rather than put in the effort :o)
>
> -----Original Message-----
> From: richardwilko [mailto:richardjohnwilkinson@...]
> Sent: Monday, June 02, 2008 10:21 AM
> To: users@...
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
>
> ok maybe i misread this :
>
> 'Can best be done in a limited fashion, where we only generify IModel
> but not components. I care more about what generifying can do for API
> clarity (declaring a component to only accept certain models for
> instance) than static type checking.'
>
> but those 2 sentences seem to contradict each other, the first says only
> generify IModel which I assumed ti mean that when you put a String into
> a model you would get a String out of it, the second seems to says
> generifiying components to make them only accept some model types.
>
> So just to clarify my position
>
> generic models which would do away with this type of casting:
> protected void onSubmit(AjaxRequestTarget target, Form form) {
>        EmailFormModel emailFormModel = (EmailFormModel)
> form.getModelObject();
>        ....
> is what I would like to see.
>
> generic components im not bothered about.
>
> if using generics wont do away with the casting then I dont see any
> point to using them at all.
>
>
>
> Johan Compagner wrote:
> >
> > why are you contradicting yourself?
> >
> > "To be honest I don't see the advantage of generic components, all I
> > want is to not have to do casting when I'm using models,
> > .getModelObject() should return the type that I put in, in a list
> > view, if I give it a list of strings I dont want to cast the listItem
> > model object to a string."
> >
> > if you have just IModel then you will have to cast.. getModelObject
> > will always return just Object then.
> >
> >
> > ok maybe i misread
> >
> > about:
> >
> > "new TextArea(...).add(some behavior).setRequired(true) "
> >
> > this can be done but then we have to override some methods of
> > component and then return another type The problem is that this could
> > result in us lifting a final where we dont want to..
> > But this is outside the scope of generics
> >
> > johan
> >
> > On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
> > <richardjohnwilkinson@...>
> > wrote:
> >
> >>
> >>
> >>   [ x ] Can best be done in a limited fashion, where we only generify
>
> >> IModel but not components. I care more about what generifying can do
> >> for API clarity (declaring a component to only accept certain models
> >> for instance) than static type checking.
> >>
> >>    [ x ] Whatever choice ultimately made, I'll happily convert/ start
>
> >> using 1.4 and up.
> >>
> >> To be honest I don't see the advantage of generic components, all I
> >> want is to not have to do casting when I'm using models,
> >> .getModelObject() should return the type that I put in, in a list
> >> view, if I give it a list of strings I dont want to cast the listItem
>
> >> model object to a string.  It would also be nice if the .add() and
> >> others methods on components could return the type of component it is
>
> >> rather than just a Component object.  eg you cant do 'new
> >> TextArea(...).add(some behavior).setRequired(true) because the add
> >> behaviour method returns a Component not a TextArea and setRequired
> >> is not available on Components.
> >>
> >> Thanks
> >> --
> >> View this message in context:
> >> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is
> >> -your-take-on-generics-with-Wicket-tp17589984p17601296.html
> >> Sent from the Wicket - User mailing list archive at Nabble.com.
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: users-unsubscribe@...
> >> For additional commands, e-mail: users-help@...
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
> ur-take-on-generics-with-Wicket-tp17589984p17602507.html<http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602507.html>
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Brill Pappin]

I think its not quite that simple.

Certainly both sets of components should use generics (silly to have a partial solution) but how its done is vital so that it doesn't become a huge mess.

I'm one of the adopters of the M1 release and I've found it quite difficult to keep things straight sometimes.

- Model objects should allow any generic needed (due tot he nature of a model).
- Components should be specific about the generics they accept i.e. instance of model etc.

makeing the generics clean will help us keep our code clean.

- Brill Pappin

Eelco Hillenius wrote:

We have had several threads in this and the dev list, and some
discussions in the public on how to incorporate generics in Wicket.

I'd like to use this thread to gather the opinions of as many regular
Wicket users as we can. Please help us get an impression of what our
users think about the issue by completing this simple survey. Note
that it is not a vote; we only want to get an idea of what you think.