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

[lzappaterrini]

I am currently using 1.4 M1 and here are my choices:

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

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

______________

The information contained in this message is proprietary and/or confidential. If you are not the
intended recipient, please: (i) delete the message and all copies; (ii) do not disclose,
distribute or use the message in any manner; and (iii) notify the sender immediately. In addition,
please be aware that any message addressed to our domain is subject to archiving and review by
persons other than the intended recipient. Thank you.
_____________

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

[whoover]

Wow, last time I checked CompoundPropertyModel is a model ;o)

-----Original Message-----
From: John Krasnay [mailto:john@...]
Sent: Monday, June 02, 2008 1:22 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 11:59:09AM -0400, Hoover, William  wrote:
> I read it, but I think most people will be using models more
> frequently than 30% of the time. Personally, I use them 99% of the
time.

Really? Haven't you heard of CompoundPropertyModel?

jk

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



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

[Al Maw]

I think you miss John's point, which is that when you use a
CompoundPropertyModel for a component, all its children typically do not
reference models explicitly.

Thus you typically use an explicit model on < 30% of your components if you
have a form-heavy web-app; the other components use the implicit model
provided by the parent's CompoundPropertyModel.

Regards,

Al

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

> Wow, last time I checked CompoundPropertyModel is a model ;o)
>
> -----Original Message-----
> From: John Krasnay [mailto:john@...]
> Sent: Monday, June 02, 2008 1:22 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 11:59:09AM -0400, Hoover, William  wrote:
> > I read it, but I think most people will be using models more
> > frequently than 30% of the time. Personally, I use them 99% of the
> time.
>
> Really? Haven't you heard of CompoundPropertyModel?
>
> jk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[atul singh-5]

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

The best way still for wicket is *to implement generics partially *and* then
start incorporating into OUT-OF-BOX(components less prone to extension)
later on in further releases.
The fact is that less people can make to wicket core-development team, and
then who will maintain the bloat(meaning undesired syntactical features).
Who will release non-generics versions for freshers.

In Design Patterns I learnt about the open-closed principle. Closed for
change and open for extension.
Generics forces us to see into a new design pattern---Generify the the most
closed only, based on use cases--If there is more of a need of extension of
classes by end user AND there is flexibility while extending(wicket is one
case which is flexible when you extend)--then wait, do not generify. *
On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset <bn@...> wrote:

> Hi all,
>
>  [X] Can best be done in a limited fashion, where we only generify
> IModel but not components. I care more about what generifying can do
> for API clarity (declaring a component to only accept certain models
> for instance) than static type checking.
>
> [X] I might rethink upgrading if my choice doesn't win.
>
>
> I didn't try wicket 1.4 yet, but I read questions and comments from users
> in this list. My impression so far has been that there has been a small
> design mistake in the way the current 1.4 implementation has been done. I
> perceive that IModel<T> is conceptually correct as a Model can be seen as a
> container of something (of type T). Writing DropDownChoice<T> is a shortcut
> that does not seem conceptually correct as in this case, the component is
> not a container of type T but a container of type IModel<T>. So you should
> have something like DropDownChoice<IModel<T>> (I know this not valid java).
> Generifying the Page component is even worse as possibly a page can hold
> components with different model types and not have a model type on its own.
> Also, wicket is designed to allow some components not to have model on their
> own and rely on the model stored in a parent component (very nice and
> powerful feature).
>
> Please note that using generic this way is already possible with wicket 1.3
> if you define an interface that would be for instance IMyModel<T> extends
> IModel. For instance, I have a generic model defined as
> DetachableBeanModel<K,T> where K is the key type and T is the bean type.
> This type is indeed a container of a key element and of a bean element.
>
> I hope it helps,
> Bernard.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[whoover]

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.

-----Original Message-----
From: alastair.maw@... [mailto:alastair.maw@...] On Behalf
Of Al Maw
Sent: Monday, June 02, 2008 2:09 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

I think you miss John's point, which is that when you use a
CompoundPropertyModel for a component, all its children typically do not
reference models explicitly.

Thus you typically use an explicit model on < 30% of your components if
you have a form-heavy web-app; the other components use the implicit
model provided by the parent's CompoundPropertyModel.

Regards,

Al

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

> Wow, last time I checked CompoundPropertyModel is a model ;o)
>
> -----Original Message-----
> From: John Krasnay [mailto:john@...]
> Sent: Monday, June 02, 2008 1:22 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 11:59:09AM -0400, Hoover, William  wrote:
> > I read it, but I think most people will be using models more
> > frequently than 30% of the time. Personally, I use them 99% of the
> time.
>
> Really? Haven't you heard of CompoundPropertyModel?
>
> jk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: 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@...

[Bernard Niset-2]

Hi Atul,
Please read again the initial post from Eelco. He explicitly wrote:
"Note that it is not a vote; we only want to get an idea of what you
think." and further away: "Thanks in advance for everyone participating,
and pls feel free to explain yourself further beyond just answering
these questions!".
Bernard.

atul singh a écrit :

> Hello everyone,
> I feel bad that a vote thread has been converted to one of discussion...
> At this moment wicket is *for *creating custom components. If these custom
> component writing gets complicated we will not be able to appreciate wicket
> as much(as much as we do now).Generics will complicate the *extend* at the
> moment for new user...I feel(after reading through everything). In core-java
> , fewer classes aim for extension by user. They rather are end product to be
> used, to be composed of.
>
> The best way still for wicket is *to implement generics partially *and* then
> start incorporating into OUT-OF-BOX(components less prone to extension)
> later on in further releases.
> The fact is that less people can make to wicket core-development team, and
> then who will maintain the bloat(meaning undesired syntactical features).
> Who will release non-generics versions for freshers.
>
> In Design Patterns I learnt about the open-closed principle. Closed for
> change and open for extension.
> Generics forces us to see into a new design pattern---Generify the the most
> closed only, based on use cases--If there is more of a need of extension of
> classes by end user AND there is flexibility while extending(wicket is one
> case which is flexible when you extend)--then wait, do not generify. *
> On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset <bn@...> wrote:
>
>  
>> Hi all,
>>
>>  [X] Can best be done in a limited fashion, where we only generify
>> IModel but not components. I care more about what generifying can do
>> for API clarity (declaring a component to only accept certain models
>> for instance) than static type checking.
>>
>> [X] I might rethink upgrading if my choice doesn't win.
>>
>>
>> I didn't try wicket 1.4 yet, but I read questions and comments from users
>> in this list. My impression so far has been that there has been a small
>> design mistake in the way the current 1.4 implementation has been done. I
>> perceive that IModel<T> is conceptually correct as a Model can be seen as a
>> container of something (of type T). Writing DropDownChoice<T> is a shortcut
>> that does not seem conceptually correct as in this case, the component is
>> not a container of type T but a container of type IModel<T>. So you should
>> have something like DropDownChoice<IModel<T>> (I know this not valid java).
>> Generifying the Page component is even worse as possibly a page can hold
>> components with different model types and not have a model type on its own.
>> Also, wicket is designed to allow some components not to have model on their
>> own and rely on the model stored in a parent component (very nice and
>> powerful feature).
>>
>> Please note that using generic this way is already possible with wicket 1.3
>> if you define an interface that would be for instance IMyModel<T> extends
>> IModel. For instance, I have a generic model defined as
>> DetachableBeanModel<K,T> where K is the key type and T is the bean type.
>> This type is indeed a container of a key element and of a bean element.
>>
>> I hope it helps,
>> Bernard.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
>  

[John Krasnay]

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

[Martin Funk-3]

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.

It is just that
A_HomePage extends the raw type of the generic type WebPage<T>

whereas
B_HomePage extends the parameterized type, with type parameter 'Void' of the
generic type WebPage<T>

So if I get it right it is not the generification of the HomePage, that
makes the difference but its weather it is derived of a parameterized type.

Esp. if the signature of 'public abstract Class<? extends Page<?>>
getHomePage();' stays that way the HomePage can't be generified.

Can someone pleas elaborate on this?

mf

2008/6/2 Sebastiaan van Erk <sebster@...>:

> 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.
>
> Regards,
> Sebastiaan
>
>
> Brill Pappin wrote:
>
>> I'm likely missing something here, but why would you want to return
>> something other than a *Page object? Wouldn't that cause some issues with
>> the application?
>>
>> Maybe I don't understand what you mean by "raw type".
>>
>> - Brill Pappin
>>
>> -----Original Message-----
>> From: Sebastiaan van Erk [mailto:sebster@...] Sent: Monday, June
>> 02, 2008 11:53 AM
>> To: users@...
>> Subject: Re: users, please give us your opinion: what is your take on
>> generics with Wicket
>>
>> James Carman wrote:
>>
>>> I'm adding a "Gotchas" section now.
>>>
>>
>> Your pallete gotcha seems more like a JIRA to me. :-) It's not really
>> about
>> generics in general, but about a specific choice in 1 component (which
>> really seems incorrect to me, i.e., PECS).
>>
>> One of the gotcha's I think is the getHomePage() signature...
>>
>>        public abstract Class<? extends Page<?>> getHomePage();
>>
>> This breaks raw types (you can't return raw home page).
>>
>> I don't see any way out of this one without making the getHomePage()
>> signature incorrect (i.e., you can't make it a generic method, which was
>> used to solve the problem where a method argument had the type Class<?
>> extends Page<?>>).
>>
>> Regards,
>> Sebastiaan
>>
>>
>>
>>
>>  On Mon, Jun 2, 2008 at 11:13 AM, Hoover, William <whoover@...>
>>>
>> wrote:
>>
>>> Sounds like a good idea... Are you going to create it?
>>>>
>>>> -----Original Message-----
>>>> From: jcarman@... [mailto:jcarman@...
>>>> ]
>>>> On Behalf Of James Carman
>>>> Sent: Monday, June 02, 2008 11:06 AM
>>>> To: users@...
>>>> Subject: Re: users, please give us your opinion: what is your take on
>>>> generics with Wicket
>>>>
>>>> Why don't we use the Wiki page to list our *specific* "gotchas" we
>>>> encounter and try to come up with a solution for them.  My guess is that we
>>>> can do so.
>>>>
>>>> On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William <whoover@...>
>>>> wrote:
>>>>
>>>>> +1
>>>>> I would like to see what the major issues are as to why people are
>>>>> rejecting model/component generics. None that I have seen so far are that
>>>>> convincing- especially the complaints of verbosity.
>>>>>
>>>>> -----Original Message-----
>>>>> From: jcarman@...
>>>>> [mailto:jcarman@...]
>>>>> On Behalf Of James Carman
>>>>> Sent: Monday, June 02, 2008 10:56 AM
>>>>> To: users@...
>>>>> Subject: Re: users, please give us your opinion: what is your take on
>>>>> generics with Wicket
>>>>>
>>>>> On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp <matej.knopp@...>
>>>>> wrote:
>>>>>
>>>>>> I'm not sure I like where this discussion is going. I don't see anyone
>>>>>> having any particular objections against current state. I think before we
>>>>>> even think of (partially) reverting generics we have to discuss what's wrong
>>>>>> (except the verbosity of course, but that's not something we can really do
>>>>>> about) with current state. I use wicket with generics daily and I don't see
>>>>>> any particular show stopper so far.
>>>>>>
>>>>>>  +1, I agree.  I think this discussion might be counter-productive if
>>>>> folks who aren't using the generified versions are voting.
>>>>>
>>>>> --------------------------------------------------------------------
>>>>> - To unsubscribe, e-mail: 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@...
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>

[Jeremy Thomerson-3]

My vote:
X - Can best be done like currently in the 1.4 branch, where models and
components are both generified
X - Whatever choice ultimately made, I'll happily convert/ start using 1.4
and up.

I have to modify that last sentence, though - because I will continue using
Wicket, because it's the best.  But I have already upgraded all of my
applications to use 1.4, and there wouldn't be any "happily" about it to
back it out and stop using generics for me.  They are too valuable to lose.
I have been using 1.4 with generics since before M1 was released, with
nearly half a dozen deployed production applications now running on either
1.4-M1 or M2.

Without intending to offend anyone, the rest of my thoughts on this:

I've read over 100 emails on this thread, and nearly all of the ones against
keeping generics like they are currently implemented are from people who do
not fully understand them and have not used them on a day-to-day basis.
I'll grant you that the first switch to 1.4 was a little intimidating, but I
had been wishing for generics in IModel since early 1.2 releases
(fortunately I never switched to 2.0).  Once you use them regularly, you
will grow to appreciate them.  I also agree that there are still some method
signatures that may be done better - we'll put those on the wiki as we come
across them.

Some are saying we don't need to "generify" component - but then you can't
call "getModelObject()" and get the right type - so generics didn't help you
within your component.  Where else will a generified model help you?  Where
are you using it that's not in a component?  Some say we should not generify
component, but they want getModelObject() to return the right type - they
don't understand generics.  There's a large discussion that says "I don't
use models in my components" - interesting, because nearly all of the
framework components use models - nearly all of my components use models - a
model is a pretty core part of a component - it's what stores the data that
the component is rendering or modifying - you can't tell the rest of us that
we shouldn't have a generic component because it wouldn't be used 70% of the
time - that's only your use case.

When we talk about new users being intimidated by Wicket because of
generics, it makes me think of the blog post by Martijn on Jonathan's
statement "don't hire wicket programmers" [1] - a good programmer with a
solid understanding of generics will not be intimidated when they start
using this framework.  This in no way implies that if you do not currently
like the generics that you are a bad programmer.  It only means that
generics are still new to some, they have not used them enough yet to be
really comfortable with them.  They are very valuable, but yes, java
could've implemented them better.  So, we'd all better get good with
generics - they've been in java for quite a while now, and they're here to
stay.  No reason Wicket shouldn't / can't do the same!

Jeremy Thomerson

1 - http://martijndashorst.com/blog/2008/03/30/dont-hire-wicket-programmers/

On Sun, Jun 1, 2008 at 3:44 PM, Eelco Hillenius <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
>   [ ] 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@...
>
>

[igor.vaynberg]

after using 1.4 full time i am more and more coming around to this
point of view also.

disclaimer: terms like "vast majority" are based on my own coding experience...

the fact is, it doesnt matter how often you use models in components,
its how often you actually have to cast the model object to a type, eg
when you call getmodelobject() or getmodel() on the component. a big
percentage of the time you bind the model to a property - like in form
components, or push in a model once and never access it again - like
in dropdownchoice choices model, generics offer you no benefit in
these two cases.

here are a couple of thoughts i have:

generics for formcomponents do not make sense, most of the time they
can figure out the type by inspecting their model. further, generics
did not get rid of the need to specify the type as a constructor
argument: new TextField<Integer>("num", Integer.class)

a lot of times there is no clear type, eg Label. should that be
Label<String>? why do i need to repeat the type twice? new
Label<String>("username", new PropertyModel<String>(this,
"username")); it is very redundant for some components. new
Label("username", new ProeprtyModel<String>(this, "usenrame")) is just
as self documenting.

a vast majority of components are "set it and forget it": add(new
TextField("foo", new PropertyModel<String>(this, "username"));
developer doesnt keep a reference to these components, so generics are
just noise, the type of the model is enough.

i think the fact remains that component's default model is just there
for user's convenience. it would really suck to have to write an
ondetach() handler every time, especially since a single model
instance per component covers 90% usecase. if java had something like
scala's traits, model would not be part of Component.

i am willing to drop component model support if the following can be met:

certain constructors stay generified to document certain aspects, eg
dropdownchoice constructor should be generified.

support generification of certain components, even if it means
removing final from certain methods. this code should still be
possible:
add(new ListView<Person>("people") { protected void
onPopulate(Item<Person> person) {.... where getModel() of that item
returns IModel<Person>

for me, the driving point is that i havent enjoyed writing wicket code
against 1.4 trunk as much.

-igor


On Mon, Jun 2, 2008 at 7:47 AM, John Krasnay <john@...> wrote:

> On Sun, Jun 01, 2008 at 01:44:59PM -0700, Eelco Hillenius wrote:
>>
>> 1) Generifying* Wicket
>>    [x] Can best be done in a limited fashion, where we only generify
>> IModel but not components. I care more about what generifying can do
>> for API clarity (declaring a component to only accept certain models
>> for instance) than static type checking.
>>
>> 2) How strongly do you feel about your choice above?
>>    [x] Whatever choice ultimately made, I'll happily convert/ start
>> using 1.4 and up.
>
> IMHO storing a model in a Component is more a convenience than a
> fundamental part of component-ness. This may be part of the reason that
> genericizing Component is so contentious.
>
> I have many components with no model and many others, such as a
> TextField that uses a parent's CompoundPropertyModel, the component has
> a model but I really don't care about the type, since I never call
> getModelObject(). In all these cases (which are easily the majority in
> my experience), genericized Components would force me to deal with the
> syntactic overhead of generics with absolutely zero value.
>
> I'm all for genericizing certain components for which the model is
> central (e.g. ListView and Item) but I think genericizing Component is
> overkill, since it's relatively rare that I care about the type of a
> component's model.
>
> jk
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[svenmeier]

IMHO we should try to keep the topic on "your take on generics", not on
"your take on others take on generics". But while we're at it:

 >I've read over 100 emails on this thread, and nearly all of the ones
against keeping generics like they are currently implemented are from
people who do not fully understand them

That *is* offending. How do you come to your conclusion that people
don't understand generics?
The following is not something I'd prefer, and I don't need to be a
master in generics to form this opinion:

  DropDownChoice<Fruit> fruit = new DropDownChoice<Fruit>("fruit", new Model<Fruit>(), ...);
  new TextField<Integer> num = new TextField<Integer>("num", Integer.class)

> you can't call "getModelObject()" and get the right type - so generics didn't help you within your component

IMHO generics should help in *using* components.

> you can't tell the rest of us that we shouldn't have a generic component because it wouldn't be used 70% of the
time - that's only your use case

I doubt that, anyone using CompoundPropertyModel will easily reach that percentage.

It just seems wrong (to me) to generify Component just for one or two getters - weren't getters the root of all evil anyway? ;).

Back to the topic:

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

  [X] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up ... what should I do otherwise, use JSF? (Just kidding)

Sven


Jeremy Thomerson schrieb:

> My vote:
> X - Can best be done like currently in the 1.4 branch, where models and
> components are both generified
> X - Whatever choice ultimately made, I'll happily convert/ start using 1.4
> and up.
>
> I have to modify that last sentence, though - because I will continue using
> Wicket, because it's the best.  But I have already upgraded all of my
> applications to use 1.4, and there wouldn't be any "happily" about it to
> back it out and stop using generics for me.  They are too valuable to lose.
> I have been using 1.4 with generics since before M1 was released, with
> nearly half a dozen deployed production applications now running on either
> 1.4-M1 or M2.
>
> Without intending to offend anyone, the rest of my thoughts on this:
>
> I've read over 100 emails on this thread, and nearly all of the ones against
> keeping generics like they are currently implemented are from people who do
> not fully understand them and have not used them on a day-to-day basis.
> I'll grant you that the first switch to 1.4 was a little intimidating, but I
> had been wishing for generics in IModel since early 1.2 releases
> (fortunately I never switched to 2.0).  Once you use them regularly, you
> will grow to appreciate them.  I also agree that there are still some method
> signatures that may be done better - we'll put those on the wiki as we come
> across them.
>
> Some are saying we don't need to "generify" component - but then you can't
> call "getModelObject()" and get the right type - so generics didn't help you
> within your component.  Where else will a generified model help you?  Where
> are you using it that's not in a component?  Some say we should not generify
> component, but they want getModelObject() to return the right type - they
> don't understand generics.  There's a large discussion that says "I don't
> use models in my components" - interesting, because nearly all of the
> framework components use models - nearly all of my components use models - a
> model is a pretty core part of a component - it's what stores the data that
> the component is rendering or modifying - you can't tell the rest of us that
> we shouldn't have a generic component because it wouldn't be used 70% of the
> time - that's only your use case.
>
> When we talk about new users being intimidated by Wicket because of
> generics, it makes me think of the blog post by Martijn on Jonathan's
> statement "don't hire wicket programmers" [1] - a good programmer with a
> solid understanding of generics will not be intimidated when they start
> using this framework.  This in no way implies that if you do not currently
> like the generics that you are a bad programmer.  It only means that
> generics are still new to some, they have not used them enough yet to be
> really comfortable with them.  They are very valuable, but yes, java
> could've implemented them better.  So, we'd all better get good with
> generics - they've been in java for quite a while now, and they're here to
> stay.  No reason Wicket shouldn't / can't do the same!
>
> Jeremy Thomerson
>
> 1 - http://martijndashorst.com/blog/2008/03/30/dont-hire-wicket-programmers/
>
> On Sun, Jun 1, 2008 at 3:44 PM, Eelco Hillenius <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
>>   [ ] 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@...

[Johan Compagner]

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

[jthomerson]

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

[Ingo Adler]

> 1) Generifying* Wicket  
>    [x] Should be avoided, I prefer the way 1.3 works. Because it works. Please improve the framework in functional details. Make it even easier to use. Make is less verbose. Keep the API stable.
>  
> 2) How strongly do you feel about your choice above?
>    [x] I might rethink upgrading if my choice doesn't win.



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

[atul singh-5]

Point!--but i thought it is intended to extract a survey kind of info(with
explanation if one has one)
Just that the information here is overflowing with untraceable debates


On Tue, Jun 3, 2008 at 12:47 AM, Bernard Niset <bn@...> wrote:

> Hi Atul,
> Please read again the initial post from Eelco. He explicitly wrote: "Note
> that it is not a vote; we only want to get an idea of what you think." and
> further away: "Thanks in advance for everyone participating, and pls feel
> free to explain yourself further beyond just answering these questions!".
> Bernard.
>
> atul singh a écrit :
>
>  Hello everyone,
>> I feel bad that a vote thread has been converted to one of discussion...
>> At this moment wicket is *for *creating custom components. If these custom
>> component writing gets complicated we will not be able to appreciate
>> wicket
>> as much(as much as we do now).Generics will complicate the *extend* at the
>> moment for new user...I feel(after reading through everything). In
>> core-java
>> , fewer classes aim for extension by user. They rather are end product to
>> be
>> used, to be composed of.
>>
>> The best way still for wicket is *to implement generics partially *and*
>> then
>> start incorporating into OUT-OF-BOX(components less prone to extension)
>> later on in further releases.
>> The fact is that less people can make to wicket core-development team, and
>> then who will maintain the bloat(meaning undesired syntactical features).
>> Who will release non-generics versions for freshers.
>>
>> In Design Patterns I learnt about the open-closed principle. Closed for
>> change and open for extension.
>> Generics forces us to see into a new design pattern---Generify the the
>> most
>> closed only, based on use cases--If there is more of a need of extension
>> of
>> classes by end user AND there is flexibility while extending(wicket is one
>> case which is flexible when you extend)--then wait, do not generify. *
>> On Mon, Jun 2, 2008 at 11:03 PM, Bernard Niset <bn@...>
>> wrote:
>>
>>
>>
>>> Hi all,
>>>
>>>  [X] Can best be done in a limited fashion, where we only generify
>>> IModel but not components. I care more about what generifying can do
>>> for API clarity (declaring a component to only accept certain models
>>> for instance) than static type checking.
>>>
>>> [X] I might rethink upgrading if my choice doesn't win.
>>>
>>>
>>> I didn't try wicket 1.4 yet, but I read questions and comments from users
>>> in this list. My impression so far has been that there has been a small
>>> design mistake in the way the current 1.4 implementation has been done. I
>>> perceive that IModel<T> is conceptually correct as a Model can be seen as
>>> a
>>> container of something (of type T). Writing DropDownChoice<T> is a
>>> shortcut
>>> that does not seem conceptually correct as in this case, the component is
>>> not a container of type T but a container of type IModel<T>. So you
>>> should
>>> have something like DropDownChoice<IModel<T>> (I know this not valid
>>> java).
>>> Generifying the Page component is even worse as possibly a page can hold
>>> components with different model types and not have a model type on its
>>> own.
>>> Also, wicket is designed to allow some components not to have model on
>>> their
>>> own and rely on the model stored in a parent component (very nice and
>>> powerful feature).
>>>
>>> Please note that using generic this way is already possible with wicket
>>> 1.3
>>> if you define an interface that would be for instance IMyModel<T> extends
>>> IModel. For instance, I have a generic model defined as
>>> DetachableBeanModel<K,T> where K is the key type and T is the bean type.
>>> This type is indeed a container of a key element and of a bean element.
>>>
>>> I hope it helps,
>>> Bernard.
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@...
>>> For additional commands, e-mail: users-help@...
>>>
>>>
>>>
>>>
>>
>>
>>
>

[Doug Donohoe]

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

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

* Note that we just went live with http://online.ddpoker.com/ on 1.4 trunk using generics.  I'd prefer not to backtrack, but will if that's what the developers decide.

Having gone through a conversion of a brand new project about 1/2 way through, I can tell you that (a) it is not that hard, (b) it is ultimately worth it, (c) my knowledge of java is better due to having to learn generics better, (d) we feel we created cleaner/more maintainable code because of generics.

I think wicket is great and seriously doubt, with good documentation, that using generics will turn people away.

[Doug Donohoe]

Stefan makes a good point.  I have raised this as an example before.  

My site (online.ddpoker.com, just went live) is a mix of A and B.  To make my code cleaner, I created several simple subclasses for cases where I don't use models.  VoidPanel, VoidContainer (only a handful, really).  

Also, since all my pages subclass my BasePage, all I had to do was change *that* page to subclass Page<Void> and voila, all my pages were proper.

I also created the following models to simply my life:  DateModel, IntegerModel, DoubleModel, etc.  I did some fancier stuff with Generics, including a decent drop-down list thing.

In the end, it was totally worth it.  Not only do I understand how wicket works much better with Generics (because the code helps document it), but my code is cleaner and easier to understand.

I also agree with Bill that developers should take the time to learn the feature.  It can be quite powerful.

-Doug

Stefan Lindner wrote:

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: [e-mail]
For additional commands, e-mail: [e-mail]

[jthomerson]

I think Stefan and Doug both summarize this well.  One additional
description of "type B" applications that seems to be appearing on this
thread is apps that are able to get by with mostly
string-property-name-based models.  Like PropertyModel,
CompoundPropertyModel, etc.

On the other hand, you have an app like Doug mentions.  This sounds similar
to what I have done on the largest Wicket site that I wrote and maintain.  I
have a common domain model across almost all sections of the site
(article-type entities, that share a common parent class, and other
entities, which are composed of a couple of common classes that contain
things like ratings, comments, and uploaded pictures / videos)....  So I
have been able to make many very reusable components that utilize models...
like a common bookmarkable paging navigator, completely bookmarkable table
that supports paging and sorting, etc.  The use of generics has greatly
cleaned up and improved the code for all these components.

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

Jeremy

On Mon, Jun 2, 2008 at 6:04 PM, Doug Donohoe <doug@...> wrote:

>
> Stefan makes a good point.  I have raised this as an example before.
>
> My site (online.ddpoker.com, just went live) is a mix of A and B.  To make
> my code cleaner, I created several simple subclasses for cases where I
> don't
> use models.  VoidPanel, VoidContainer (only a handful, really).
>
> Also, since all my pages subclass my BasePage, all I had to do was change
> *that* page to subclass Page<Void> and voila, all my pages were proper.
>
> I also created the following models to simply my life:  DateModel,
> IntegerModel, DoubleModel, etc.  I did some fancier stuff with Generics,
> including a decent drop-down list thing.
>
> In the end, it was totally worth it.  Not only do I understand how wicket
> works much better with Generics (because the code helps document it), but
> my
> code is cleaner and easier to understand.
>
> I also agree with Bill that developers should take the time to learn the
> feature.  It can be quite powerful.
>
> -Doug
>
>
> Stefan Lindner wrote:
> >
> > 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@...
> >
> >
> >
>
> --
> 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-tp17589984p17612786.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@...
>
>

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

[jwcarman]

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

[Timo Rantalaiho]

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" -- ?

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