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

[igor.vaynberg]

i guess my question is: if you have a list and you are never going to
put anything inside it, do you think a generic type is still useful?
there are plenty of usecases where component's default model slot is
not used, so why do we have to generify it? even if the mix is 50/50
that means 50% is complete noise...

verbousity might not be wicket's problem, but using a verbose api
sucks. generics fit for collections because there is never a case
where you would want a collection without putting/getting something
out of it.

-igor


On Mon, Jun 2, 2008 at 7:48 PM, James Carman <james@...> wrote:

> On Mon, Jun 2, 2008 at 10:30 PM, Jeremy Thomerson
> <jeremy@...> wrote:
>
>> Basically, my feeling remains the same - generics are part of Java, so Java
>> programmers are going to have to get use to them.  They are very valuable
>> when you need them.  We just have to be careful that we implement them the
>> right way.  Let's document very well the pain points on the wiki (and
>> verbosity isn't Wicket's pain point - it's java's).
>
> +1.  I've already added a couple of pain points to the wiki.  Please
> feel free to add your own specific examples of where you think
> generics has made the code difficult.
>
> ---------------------------------------------------------------------
> 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...  

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:lindner@...]
Sent: Monday, June 02, 2008 12:13 PM
To: users@...
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 'Link<Void>', 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 Link<Void>? 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

---------------------------------------------------------------------
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@...

[igor.vaynberg]

On Mon, Jun 2, 2008 at 8:24 PM, Timo Rantalaiho <Timo.Rantalaiho@...> wrote:
> On Mon, 02 Jun 2008, Igor Vaynberg wrote:
>> i am willing to drop component model support if the following can be met:
>
> "component model support" -- ?

generifying component for the sake of having a generified model.

-igor

>
>> certain constructors stay generified to document certain aspects, eg
>> dropdownchoice constructor should be generified.
>>
>> support generification of certain components, even if it means
>> removing final from certain methods. this code should still be
>> possible:
>> add(new ListView<Person>("people") { protected void
>> onPopulate(Item<Person> person) {.... where getModel() of that item
>> returns IModel<Person>
>
> Thanks Igor, you saved me a lot of typing :) A thoughtful
> message.
>
> +1
>
>
> Best wishes,
> Timo
>
> --
> Timo Rantalaiho
> Reaktor Innovations Oy    <URL: http://www.ri.fi/ >
>
> ---------------------------------------------------------------------
> 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]

+1

I think that's the right thing to do... No point making it so rigid.

- Brill Pappin

-----Original Message-----
From: jcarman@... [mailto:jcarman@...] On
Behalf Of James Carman
Sent: Monday, June 02, 2008 12:13 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

On Mon, Jun 2, 2008 at 12:11 PM, Sebastiaan van Erk <sebster@...>
wrote:
> A raw type is a parameterized type in which the type parameters are
> not filled in, i.e., new HashMap() (instead of new HashMap<String,
Integer>()).
>
> Just try to return one of your old (non-generified) HomePage.class
> classes (i.e., HomePage extends WebPage instead of HomePage extends
> WebPage<Void>) in your WebApplication's getHomePage() method, and you
> will see that it does not compile.

There is a section on the wiki addressing this now.  I would propose that
whenever referring to "class objects that represent Page subclasses" we use
Class<? extends Page> rather than Class<? extends Page<?>>.  This allows us
to specify that it has to be a page class, but it doesn't make the page
class have to be generified.

---------------------------------------------------------------------
To unsubscribe, e-mail: 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 that this has turned into a discussion is vital :)

We can't all do the work and don't have the final say, but there is nothing
like getting ideas out in the open like talking about them (even arguing
about them).

I'm glad you contributed your input!

- Brill Pappin

-----Original Message-----
From: atul singh [mailto:singhatulkr@...]
Sent: Monday, June 02, 2008 2:25 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

Hello everyone,
I feel bad that a vote thread has been converted to one of discussion...
At this moment wicket is *for *creating custom components. If these custom
component writing gets complicated we will not be able to appreciate wicket
as much(as much as we do now).Generics will complicate the *extend* at the
moment for new user...I feel(after reading through everything). In core-java
, fewer classes aim for extension by user. They rather are end product to be
used, to be composed of.


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

[Brill Pappin]

Ahh... But there in lines the real point.

What happens 2 years down the road when you need to modify that component?
A) if its not typed then you hunt around and try and find out what it was...
Maybe you do a println of the fqn...
B) its typed... Your done.

Even the time it takes to "discover" the model has direct bearing on ROI
(although a lot of developers tend not to think on it much, we all depend on
it) and the stats (and experience) say 80% of your work is maintenance.

So, forget the 20%, lets chew away some of that 80%.

- Brill Pappin

-----Original Message-----
From: John Krasnay [mailto:john@...]
Sent: Monday, June 02, 2008 3:28 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

On Mon, Jun 02, 2008 at 03:05:46PM -0400, Hoover, William  wrote:
> I got the point, but I take things as people state them. It was stated
> that 70% of the time models are not being used (such is the case for
> Link<Void>). As you stated, they are being used indirectly. That is
> different. If that is the case then I agree that the percentage of
> components using model indirectly would be reduced for "form-heavy"
> applications (as you stated). On the contrary, a lot of applications
> are not "form-heavy" (i.e. Ajax heavy apps, etc.) which also need to
> be accounted for in the figures.
>

I would contend that the important thing to look at is not the percentage of
component instances that use models, but the percent for which your code
explicitly calls getModel() or getModelObject(). If you're not calling one
of these methods, you have received no value for typing the generic syntax.
I would be surprised if I explicitly call one of these methods on more than
about 20% of my Wicket component instances.

So for me, it's not the verbosity of generics that is the problem. When the
syntax is helping you avoid a cast somewhere else, it's worth it.
What bothers me is that 80% of time (for me, anyway) it doesn't save me a
cast, it just makes for more typing and less readable code.

(Also, please keep in mind I'm referring to genericizing Component. Like
most on this thread I'm a big fan of genericizing IModel.)

jk

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


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

[Brill Pappin]

 
+1

Nicely put...
But I would say that since I agree with you :)

- Brill Pappin

-----Original Message-----
From: jeremythomerson@... [mailto:jeremythomerson@...] On Behalf
Of Jeremy Thomerson
Sent: Monday, June 02, 2008 3:39 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

[...]


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

[igor.vaynberg]

im really curious to hear what these changes would be...

-igor

On Mon, Jun 2, 2008 at 8:25 PM, Brill Pappin <brill@...> 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:lindner@...]
> Sent: Monday, June 02, 2008 12:13 PM
> To: users@...
> 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 'Link<Void>', 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 Link<Void>? 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
>
> ---------------------------------------------------------------------
> 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@...
>
>

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

[Brill Pappin]

Hold on there... Why would you suppress warnings?

I think I must miss the point of it because I don't *ever* want an API to
decide what warnings I should and shouldn't see.

 -Brill Pappin

-----Original Message-----
From: Jeremy Thomerson [mailto:jeremy@...]
Sent: Monday, June 02, 2008 6:05 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

I agree with the Class<? extends Page> with @SuppressWarnings in the
framework code.  It makes it easier, and there's no drawback either way.

Jeremy

On Mon, Jun 2, 2008 at 4:54 PM, Johan Compagner <jcompagner@...>
wrote:

> On Mon, Jun 2, 2008 at 9:33 PM, Martin Funk
> <mafulafunk@...>
> wrote:
>
> > Hi Sebastiann,
> >
> > just for clarifying my understanding of the vocabulary:
> >
> > A_HomePage extends WebPage
> > and
> > B_HomePage extends WebPage<Void>
> > are both non-generified java classes.
>
>
> No the last one is generified..
> The first one is a raw type.
>
>
> >
> >
> >
> > Esp. if the signature of 'public abstract Class<? extends Page<?>>
> > getHomePage();' stays that way the HomePage can't be generified.
> >
> >
> No as far as i can see, the home page MUST be generified thats the
> whole problem with that constructo What would happen if we did:
>
> public abstract Class<? extends Page>
>
> and have a supresswarning in our code.
>
> johanm
>

--
Jeremy Thomerson
http://www.wickettraining.com


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

[Brill Pappin]

 I know your trying to make a point about extra work for no gain, however I
can't see why I'd bother to create a list and never put anything inside it
(maybe and edge case or two)... And I couldn't think of any case where I'm
not going to use a component or model I add to a page... Why would I even
bother to implement it at all?

- Brill Pappin

-----Original Message-----
From: Igor Vaynberg [mailto:igor.vaynberg@...]
Sent: Monday, June 02, 2008 11:25 PM
To: users@...
Subject: Re: AW: users, please give us your opinion: what is your take on
generics with Wicket

i guess my question is: if you have a list and you are never going to put
anything inside it, do you think a generic type is still useful?
there are plenty of usecases where component's default model slot is not
used, so why do we have to generify it? even if the mix is 50/50 that means
50% is complete noise...

verbousity might not be wicket's problem, but using a verbose api sucks.
generics fit for collections because there is never a case where you would
want a collection without putting/getting something out of it.

-igor



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

[Brill Pappin]

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:igor.vaynberg@...]
Sent: Monday, June 02, 2008 11:42 PM
To: users@...
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 <brill@...> 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:lindner@...]
> Sent: Monday, June 02, 2008 12:13 PM
> To: users@...
> 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 'Link<Void>', 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
> Link<Void>? 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
>
> ---------------------------------------------------------------------
> 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@...
>
>

---------------------------------------------------------------------
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@...

[igor.vaynberg]

but there are plenty of cases where you will create a component with a
model and never call getmodelobject or getmodel on it.

-igor

On Mon, Jun 2, 2008 at 8:48 PM, Brill Pappin <brill@...> wrote:

>  I know your trying to make a point about extra work for no gain, however I
> can't see why I'd bother to create a list and never put anything inside it
> (maybe and edge case or two)... And I couldn't think of any case where I'm
> not going to use a component or model I add to a page... Why would I even
> bother to implement it at all?
>
> - Brill Pappin
>
> -----Original Message-----
> From: Igor Vaynberg [mailto:igor.vaynberg@...]
> Sent: Monday, June 02, 2008 11:25 PM
> To: users@...
> Subject: Re: AW: users, please give us your opinion: what is your take on
> generics with Wicket
>
> i guess my question is: if you have a list and you are never going to put
> anything inside it, do you think a generic type is still useful?
> there are plenty of usecases where component's default model slot is not
> used, so why do we have to generify it? even if the mix is 50/50 that means
> 50% is complete noise...
>
> verbousity might not be wicket's problem, but using a verbose api sucks.
> generics fit for collections because there is never a case where you would
> want a collection without putting/getting something out of it.
>
> -igor
>
>
>
> ---------------------------------------------------------------------
> 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@...

[igor.vaynberg]

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 <brill@...> 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:igor.vaynberg@...]
> Sent: Monday, June 02, 2008 11:42 PM
> To: users@...
> 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 <brill@...> 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:lindner@...]
>> Sent: Monday, June 02, 2008 12:13 PM
>> To: users@...
>> 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 'Link<Void>', 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
>> Link<Void>? 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
>>
>> ---------------------------------------------------------------------
>> 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@...
>>
>>
>
> ---------------------------------------------------------------------
> 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@...
>
>

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

[Roberto Fasciolo]

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.

[Marcus Mattila-2]

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

[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

[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.

[Martin Funk-3]

Johan Compagner wrote:

> On Mon, Jun 2, 2008 at 9:33 PM, Martin Funk <mafulafunk@...>
> wrote:
>
>  
>> Hi Sebastiann,
>>
>> just for clarifying my understanding of the vocabulary:
>>
>> A_HomePage extends WebPage
>> and
>> B_HomePage extends WebPage<Void>
>> 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 WebPage<Void>
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: users-unsubscribe@...
For additional commands, e-mail: users-help@...

[Johan Compagner]

If only... if only
we had this construct:

class Component<T default Void>
{
}

then all our problems with verbosity would be gone..

TextField tf = new TextField("id") // just default Void

Also only declare it once:

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


And both ways type guessing, so

TextField<String> tf = new TextField("id", new Model()); //textfield and
model are both just <String>
or
TextField tf = new TextField("id", new Model<String>()); // 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 <marcus.mattila@...>
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 TextField<Integer>("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: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[whoover]

In java 1.7 it will allow: TextField<Stirng> 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:jcompagner@...]
Sent: Tuesday, June 03, 2008 4:15 AM
To: users@...
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 Component<T default Void>
{
}

then all our problems with verbosity would be gone..

TextField tf = new TextField("id") // just default Void

Also only declare it once:

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


And both ways type guessing, so

TextField<String> tf = new TextField("id", new Model()); //textfield and
model are both just <String> or TextField tf = new TextField("id", new
Model<String>()); // 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
<marcus.mattila@...>
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 TextField<Integer>("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: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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