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

[Brill Pappin]

I guess I'm not understanding why people feel strongly against generics in
the components.

The model is going to use them for the data they contain, but the component
would use them for the model it uses:

MyModel<String> mymodel = new MyModel<String>();

MyComponent<MyModel> mycom = new MyComponent<MyModel>();

And that's all you would ever see of the generics unless you actually
override one of the components methods (as in a button onclick).

To top it off, I'm not even sure you would have to specify the generics for
the component (not up on my generics coding)... But  if the warning was
bugging you, you could simply use a suppress annotation (suppress should
absolutely not be in the API).

More verbose? Yes... Not by much, but it is... However the advantages gained
in terms of readability and type safety are enormous.

- Brill Pappin
 

-----Original Message-----
From: Mike Comb [mailto:mcomb@...]
Sent: Tuesday, June 03, 2008 4:39 PM
To: users@...
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket

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

I've spent a couple of afternoons trying to move our app to m1.  My
experience has been that generics on components are absolutely not worth it
for our use cases.  I love generics on objects that directly hold data
(IModel), but they are too verbose and not very useful for objects that are
a few levels removed from the actual data.

>   [X ] Whatever choice ultimately made, I'll happily convert/ start
> using 1.4 and up.

"Happily" probably isn't the word I'd chose, but we'll move to 1.4
eventually regardless of the decision made.

-Mike

--
Mike Comb
Director of Engineering
SoftCoin, Inc
mcomb@...



---------------------------------------------------------------------
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]

 
You will wait a long time for an example generated from "the API would be
different" in such and such a case, based on an opinion.

If your really all that interested you could start from scratch using
generics and see what came out.
Let me know if you do, because I'd be interested to see if my opinion held
any merit.

However, if your interested in why I said that in the first place, then I
can explain that.

I don't know if you have every done true TDD (most people can't or think
they can), but it actually changes your code and the way you write it.
Starting with 2 users of your code makes a significant impact on what it
looks like in the end.
I applied the same thoughts to using generics from the start, and realized
the API would likely be a bit different. Exactly how much, I wouldn't
presume to guess.

- Brill Pappin

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

sorry, still waiting for an example here...

-igor

On Tue, Jun 3, 2008 at 7:53 PM, Brill Pappin <brill@...> wrote:

> Actually, i did not say "... say that wicket api needs a radical
> refactoring in order to support generics" what I actually said was "I
> think that if Wicket had been written with generics from the
> beginning, the API would be different".
>
> No "radical refactoring required" was mentioned :)
>
> Big difference... It would be WAY too much work to rewrite it now, and
> I think your right that it can be implemented fairly well without too
> much impact on the users.
>
> - Brill Pappin
>
> -----Original Message-----
> From: Igor Vaynberg [mailto:igor.vaynberg@...]
> Sent: Tuesday, June 03, 2008 12:21 AM
> To: users@...
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
> you made a radical statement, just wandering if there is anything
> concrete you can back it up with. in my head the generics have very
> little effect on the actual api design so i am wandering what prompted
> you to say that wicket api needs a radical refactoring in order to
> support generics - which essentially are little more then metadata.
>
> -igor
>
> On Mon, Jun 2, 2008 at 8:50 PM, Brill Pappin <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@...
>
>
> ---------------------------------------------------------------------
> 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]

no worries, i wasnt holding my breath. its just that when i make
sweeping statements i tend to have something to back them up that
other people can see...

-igor

On Tue, Jun 3, 2008 at 8:19 PM, Brill Pappin <brill@...> wrote:

>
> You will wait a long time for an example generated from "the API would be
> different" in such and such a case, based on an opinion.
>
> If your really all that interested you could start from scratch using
> generics and see what came out.
> Let me know if you do, because I'd be interested to see if my opinion held
> any merit.
>
> However, if your interested in why I said that in the first place, then I
> can explain that.
>
> I don't know if you have every done true TDD (most people can't or think
> they can), but it actually changes your code and the way you write it.
> Starting with 2 users of your code makes a significant impact on what it
> looks like in the end.
> I applied the same thoughts to using generics from the start, and realized
> the API would likely be a bit different. Exactly how much, I wouldn't
> presume to guess.
>
> - Brill Pappin
>
> -----Original Message-----
> From: Igor Vaynberg [mailto:igor.vaynberg@...]
> Sent: Tuesday, June 03, 2008 11:03 PM
> To: users@...
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
> sorry, still waiting for an example here...
>
> -igor
>
> On Tue, Jun 3, 2008 at 7:53 PM, Brill Pappin <brill@...> wrote:
>> Actually, i did not say "... say that wicket api needs a radical
>> refactoring in order to support generics" what I actually said was "I
>> think that if Wicket had been written with generics from the
>> beginning, the API would be different".
>>
>> No "radical refactoring required" was mentioned :)
>>
>> Big difference... It would be WAY too much work to rewrite it now, and
>> I think your right that it can be implemented fairly well without too
>> much impact on the users.
>>
>> - Brill Pappin
>>
>> -----Original Message-----
>> From: Igor Vaynberg [mailto:igor.vaynberg@...]
>> Sent: Tuesday, June 03, 2008 12:21 AM
>> To: users@...
>> Subject: Re: users, please give us your opinion: what is your take on
>> generics with Wicket
>>
>> you made a radical statement, just wandering if there is anything
>> concrete you can back it up with. in my head the generics have very
>> little effect on the actual api design so i am wandering what prompted
>> you to say that wicket api needs a radical refactoring in order to
>> support generics - which essentially are little more then metadata.
>>
>> -igor
>>
>> On Mon, Jun 2, 2008 at 8:50 PM, Brill Pappin <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@...
>>
>>
>> ---------------------------------------------------------------------
>> 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@...

[mcomb]

Well, in our case it would almost never be:

MyComponent<MyModel> mycom = new MyComponent<MyModel>();

We don't have many of our own models, we use CompoundPropertyModel  
pretty much exclusively (wrapping DAOs or javabeans).  So the  
verbosity doesn't benefit us much.  Also, the vast majority of our  
components don't have a model.  We generally have a page containing  
one or more forms with a CompoundPropModel on each form.  Having  
generics (particularly if they are just something like <Void>) on  
every other object in the page is messy and confusing in my mind.

Telling people to use suppress annotations is not a good solution  
either, we want those warnings for other things in our code  
(Collections, etc).

-Mike

On Jun 3, 2008, at 8:11 PM, Brill Pappin wrote:

> I guess I'm not understanding why people feel strongly against  
> generics in
> the components.
>
> The model is going to use them for the data they contain, but the  
> component
> would use them for the model it uses:
>
> MyModel<String> mymodel = new MyModel<String>();
>
> MyComponent<MyModel> mycom = new MyComponent<MyModel>();
>
> And that's all you would ever see of the generics unless you actually
> override one of the components methods (as in a button onclick).
>
> To top it off, I'm not even sure you would have to specify the  
> generics for
> the component (not up on my generics coding)... But  if the warning  
> was
> bugging you, you could simply use a suppress annotation (suppress  
> should
> absolutely not be in the API).
>
> More verbose? Yes... Not by much, but it is... However the  
> advantages gained
> in terms of readability and type safety are enormous.
>
> - Brill Pappin
>
>
> -----Original Message-----
> From: Mike Comb [mailto:mcomb@...]
> Sent: Tuesday, June 03, 2008 4:39 PM
> To: users@...
> Subject: Re: users, please give us your opinion: what is your take on
> generics with Wicket
>
>>  [X ] Can best be done in a limited fashion, where we only generify
>> IModel but not components. I care more about what generifying can do
>> for API clarity (declaring a component to only accept certain models
>> for instance) than static type checking.
>
> I've spent a couple of afternoons trying to move our app to m1.  My
> experience has been that generics on components are absolutely not  
> worth it
> for our use cases.  I love generics on objects that directly hold data
> (IModel), but they are too verbose and not very useful for objects  
> that are
> a few levels removed from the actual data.
>
>>  [X ] Whatever choice ultimately made, I'll happily convert/ start
>> using 1.4 and up.
>
> "Happily" probably isn't the word I'd chose, but we'll move to 1.4
> eventually regardless of the decision made.
>
> -Mike
>
> --
> Mike Comb
> Director of Engineering
> SoftCoin, Inc
> mcomb@...
>
>
>
> ---------------------------------------------------------------------
> 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@...
>

--
Mike Comb
Director of Engineering
SoftCoin, Inc
mcomb@...



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

[Eelco Hillenius]

On Tue, Jun 3, 2008 at 8:54 PM, Mike Comb <mcomb@...> wrote:

> Well, in our case it would almost never be:
>
> MyComponent<MyModel> mycom = new MyComponent<MyModel>();
>
> We don't have many of our own models, we use CompoundPropertyModel pretty
> much exclusively (wrapping DAOs or javabeans).  So the verbosity doesn't
> benefit us much.  Also, the vast majority of our components don't have a
> model.  We generally have a page containing one or more forms with a
> CompoundPropModel on each form.  Having generics (particularly if they are
> just something like <Void>) on every other object in the page is messy and
> confusing in my mind.

Yep.

> Telling people to use suppress annotations is not a good solution either, we
> want those warnings for other things in our code (Collections, etc).

Yep.

Eelco

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

[igor.vaynberg]

i think we should have qualified this rfi with a requirement that
responders use 1.4 on a non-trivial project...these things only become
apparent from real-world day-to-day usage. anything else is pretty
much speculation.

-igor

On Tue, Jun 3, 2008 at 10:31 PM, Eelco Hillenius
<eelco.hillenius@...> wrote:

> On Tue, Jun 3, 2008 at 8:54 PM, Mike Comb <mcomb@...> wrote:
>> Well, in our case it would almost never be:
>>
>> MyComponent<MyModel> mycom = new MyComponent<MyModel>();
>>
>> We don't have many of our own models, we use CompoundPropertyModel pretty
>> much exclusively (wrapping DAOs or javabeans).  So the verbosity doesn't
>> benefit us much.  Also, the vast majority of our components don't have a
>> model.  We generally have a page containing one or more forms with a
>> CompoundPropModel on each form.  Having generics (particularly if they are
>> just something like <Void>) on every other object in the page is messy and
>> confusing in my mind.
>
> Yep.
>
>> Telling people to use suppress annotations is not a good solution either, we
>> want those warnings for other things in our code (Collections, etc).
>
> Yep.
>
> Eelco
>
> ---------------------------------------------------------------------
> 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@...

[Eelco Hillenius]

On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg <igor.vaynberg@...> wrote:
> i think we should have qualified this rfi with a requirement that
> responders use 1.4 on a non-trivial project...these things only become
> apparent from real-world day-to-day usage. anything else is pretty
> much speculation.

Well, like I stated I just wanted to get a hunch of what people think,
not so much an informed discussion. I think it is very clear now that
whatever choice we'll ultimately stick to, it will make part of our
user base unhappy, and might have to do some evangelizing to get the
changes accepted by everyone (or most) :-)

As for speculation... I don't agree. I haven't converted yet, but it
is easy enough to just look at any old piece of code I'm working on
now and imagine what it will look like after changing to 1.4.

Eelco

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

[igor.vaynberg]

On Tue, Jun 3, 2008 at 11:30 PM, Eelco Hillenius
<eelco.hillenius@...> wrote:
> On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg <igor.vaynberg@...> wrote:
>> i think we should have qualified this rfi with a requirement that
>> responders use 1.4 on a non-trivial project...these things only become
>> apparent from real-world day-to-day usage. anything else is pretty
>> much speculation.
>
> As for speculation... I don't agree. I haven't converted yet, but it
> is easy enough to just look at any old piece of code I'm working on
> now and imagine what it will look like after changing to 1.4.

and there are also a lot of pain points that you will not imagine that
do exist :) i am wondering how many of the "keep as is in trunk" votes
came from people who only imagined what their code would look like and
havent actually hit the numerous pain points those of us who did code
gainst it hit.

i was of the "generify component and model" mind while i was
generifying the framework, but after coding against it i began to see
some of the ugliness and now my mind is almost changed.

-igor


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

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

[Jan Kriesten]

> i was of the "generify component and model" mind while i was
> generifying the framework, but after coding against it i began to see
> some of the ugliness and now my mind is almost changed.

yep, day to day usage is the main point.

i came to that conclusion as well when i was trying to migrate somewhat
non-trivial use of wicket to 1.4 base. the standard components like link et al
aren't the real problem (though it doesn't look pretty), it gets complicated
when you're using "non-trivial" components (like datatable and their dependents)
where the type on the component gets in your way.



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

[Stefan Lindner]

Igor Vaynberg wrote

>i am wondering how many of the "keep as is in trunk" votes came from
people who only imagined what their code would look like and havent
>actually hit the numerous pain points those of us who did code gainst
it hit.

I'm one of the "keep as is in trunk" users and I use 1.4 trunk from the
beginning. I use it in a big real world application. But: I am one of
the former 2.0 users and accustomed to generic Components in Wicket.
Maybe I have made my workaround strategy for some generic problems more
than a year ago.

One experience I made was that I realized that I made no use of Models
when I startet using Wicket from 1.0. Instead of having

        public class MyPanel extends Panel<MyData>

                public MyPanel(String id, IModel<MyData> model) {
                        ...

I used constructs like

        public class MyPanel extends Panel

                public MyPanel(String id, MyData myData) {
                        ...

like I was used to do in other frameworks. The second one was the only
way to have a typesafe treatment of MyData when Model was non generic.
It took a while to realize that the Models in Wicket are very usefull
thing and the tight Component-Model coupling leads to better
Applications

Maybe the posts like "I do not use Models" or "Only 20% or our
components have Models" come from the same background as my early wicket
adoption.

Stefan

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

[Jan Kriesten]

hi stefan,

> Maybe the posts like "I do not use Models" or "Only 20% or our
> components have Models" come from the same background as my early wicket
> adoption.

i don't think you use compoundpropertymodels very often, so your mileage may be
very different how often you use component models.

another example: inner classes/components don't have a model on my apps very
often, since they access the parents model/state directly.

it all depends, on how and what you're developing.

best regards, --- jan.

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

[Eelco Hillenius]

> it all depends, on how and what you're developing.

Yeah. I actually use less and less models in the regular way nowadays.
I use plenty of panels (the app I work on hardly uses separate pages)
that nest other panels in them (typically detail views or dialogs)
that reuse models of the parent. But indeed YMMV.

Personally, I think the whole generics business exposes that the
one-one relation between components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor, but as generics aren't as 'optional' it is all very in
your face suddenly.

I think on the longer term (post 1.4) we should re-think how models
work in Wicket. See if we can find an elegant way to make this more
flexible (I'm not in favor of the id based thing someone posted
earlier btw) without breaking the whole world.

FWIW, I'm still on the fence when it comes to whether we should go for
a full or partial (models only) implementation of generics, though I'm
leaning towards partial.

Eelco

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

[Johan Compagner]

i think the only real other way is what is already possible
Just dont keep references to the Component (just add them to there parents)
and keep references to the models of those components.
and work with models only

johan


On Wed, Jun 4, 2008 at 10:24 AM, Eelco Hillenius <eelco.hillenius@...>
wrote:

> > it all depends, on how and what you're developing.
>
> Yeah. I actually use less and less models in the regular way nowadays.
> I use plenty of panels (the app I work on hardly uses separate pages)
> that nest other panels in them (typically detail views or dialogs)
> that reuse models of the parent. But indeed YMMV.
>
> Personally, I think the whole generics business exposes that the
> one-one relation between components and models is flawed. Without
> generics this isn't much of a problem, just the odd unused member and
> constructor, but as generics aren't as 'optional' it is all very in
> your face suddenly.
>
> I think on the longer term (post 1.4) we should re-think how models
> work in Wicket. See if we can find an elegant way to make this more
> flexible (I'm not in favor of the id based thing someone posted
> earlier btw) without breaking the whole world.
>
> FWIW, I'm still on the fence when it comes to whether we should go for
> a full or partial (models only) implementation of generics, though I'm
> leaning towards partial.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[jwcarman]

On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
<eelco.hillenius@...> wrote:

>> it all depends, on how and what you're developing.
>
> Yeah. I actually use less and less models in the regular way nowadays.
> I use plenty of panels (the app I work on hardly uses separate pages)
> that nest other panels in them (typically detail views or dialogs)
> that reuse models of the parent. But indeed YMMV.
>
> Personally, I think the whole generics business exposes that the
> one-one relation between components and models is flawed. Without
> generics this isn't much of a problem, just the odd unused member and
> constructor, but as generics aren't as 'optional' it is all very in
> your face suddenly.
>
> I think on the longer term (post 1.4) we should re-think how models
> work in Wicket. See if we can find an elegant way to make this more
> flexible (I'm not in favor of the id based thing someone posted
> earlier btw) without breaking the whole world.
>

We discussed this on ##wicket yesterday.  I asked why we have models
on all components and someone pointed out that the main reason was
about the detach stuff I believe.  But, couldn't that be solved by
having some components that implement something like IModelDriven (or
IModelBacked or whatever) and the detach logic could apply to only
those components?  Also, someone has pointed out that when they create
their own components, they sometimes (such as in Palette) have
multiple "models" that they deal with.  Allowing components to name
their models what they want would be nice, too.

> FWIW, I'm still on the fence when it comes to whether we should go for
> a full or partial (models only) implementation of generics, though I'm
> leaning towards partial.
>
> Eelco
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[Matej Knopp]

There are also implementation issues that need to be considered.
Currently the model is stored in a way that it doesn't take any place
when not used.
Having multiple models is rare, however, having one model that can
(but doesn't have to) be used is more common imho. Wicket is kinda
optimized for the later, so if you don't use the model there is no
runtime cost associated. If we didn't have "default" model slot this
would be more difficult to achieve.

-Matej

On Wed, Jun 4, 2008 at 12:37 PM, James Carman
<james@...> wrote:

> On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
> <eelco.hillenius@...> wrote:
>>> it all depends, on how and what you're developing.
>>
>> Yeah. I actually use less and less models in the regular way nowadays.
>> I use plenty of panels (the app I work on hardly uses separate pages)
>> that nest other panels in them (typically detail views or dialogs)
>> that reuse models of the parent. But indeed YMMV.
>>
>> Personally, I think the whole generics business exposes that the
>> one-one relation between components and models is flawed. Without
>> generics this isn't much of a problem, just the odd unused member and
>> constructor, but as generics aren't as 'optional' it is all very in
>> your face suddenly.
>>
>> I think on the longer term (post 1.4) we should re-think how models
>> work in Wicket. See if we can find an elegant way to make this more
>> flexible (I'm not in favor of the id based thing someone posted
>> earlier btw) without breaking the whole world.
>>
>
> We discussed this on ##wicket yesterday.  I asked why we have models
> on all components and someone pointed out that the main reason was
> about the detach stuff I believe.  But, couldn't that be solved by
> having some components that implement something like IModelDriven (or
> IModelBacked or whatever) and the detach logic could apply to only
> those components?  Also, someone has pointed out that when they create
> their own components, they sometimes (such as in Palette) have
> multiple "models" that they deal with.  Allowing components to name
> their models what they want would be nice, too.
>
>> FWIW, I'm still on the fence when it comes to whether we should go for
>> a full or partial (models only) implementation of generics, though I'm
>> leaning towards partial.
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 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@...

[Johan Compagner]

soo

interface IModelComponent<T>
{
     public IModel<T> getModel()
}

and remove getModel/getModelObject methods from component itself?

But then everybody that does use models have to implement it..




On Wed, Jun 4, 2008 at 12:37 PM, James Carman <james@...>
wrote:

> On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
> <eelco.hillenius@...> wrote:
> >> it all depends, on how and what you're developing.
> >
> > Yeah. I actually use less and less models in the regular way nowadays.
> > I use plenty of panels (the app I work on hardly uses separate pages)
> > that nest other panels in them (typically detail views or dialogs)
> > that reuse models of the parent. But indeed YMMV.
> >
> > Personally, I think the whole generics business exposes that the
> > one-one relation between components and models is flawed. Without
> > generics this isn't much of a problem, just the odd unused member and
> > constructor, but as generics aren't as 'optional' it is all very in
> > your face suddenly.
> >
> > I think on the longer term (post 1.4) we should re-think how models
> > work in Wicket. See if we can find an elegant way to make this more
> > flexible (I'm not in favor of the id based thing someone posted
> > earlier btw) without breaking the whole world.
> >
>
> We discussed this on ##wicket yesterday.  I asked why we have models
> on all components and someone pointed out that the main reason was
> about the detach stuff I believe.  But, couldn't that be solved by
> having some components that implement something like IModelDriven (or
> IModelBacked or whatever) and the detach logic could apply to only
> those components?  Also, someone has pointed out that when they create
> their own components, they sometimes (such as in Palette) have
> multiple "models" that they deal with.  Allowing components to name
> their models what they want would be nice, too.
>
> > FWIW, I'm still on the fence when it comes to whether we should go for
> > a full or partial (models only) implementation of generics, though I'm
> > leaning towards partial.
> >
> > Eelco
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@...
> > For additional commands, e-mail: users-help@...
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Matej Knopp]

I don't really think this is the right discussion we should be having now :)
Maybe 1.5 would be the right release for changes like that (if they
are justified, which i'm not really convinced it is. Anyway, as I said
before, storing (single) model in component has no overhead, so I
don't really see the point. Maybe we could make the methods protected
and components that actually use the default model would make them
public, dunno.

-Matej

On Wed, Jun 4, 2008 at 1:59 PM, Johan Compagner <jcompagner@...> wrote:

> soo
>
> interface IModelComponent<T>
> {
>     public IModel<T> getModel()
> }
>
> and remove getModel/getModelObject methods from component itself?
>
> But then everybody that does use models have to implement it..
>
>
>
>
> On Wed, Jun 4, 2008 at 12:37 PM, James Carman <james@...>
> wrote:
>
>> On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
>> <eelco.hillenius@...> wrote:
>> >> it all depends, on how and what you're developing.
>> >
>> > Yeah. I actually use less and less models in the regular way nowadays.
>> > I use plenty of panels (the app I work on hardly uses separate pages)
>> > that nest other panels in them (typically detail views or dialogs)
>> > that reuse models of the parent. But indeed YMMV.
>> >
>> > Personally, I think the whole generics business exposes that the
>> > one-one relation between components and models is flawed. Without
>> > generics this isn't much of a problem, just the odd unused member and
>> > constructor, but as generics aren't as 'optional' it is all very in
>> > your face suddenly.
>> >
>> > I think on the longer term (post 1.4) we should re-think how models
>> > work in Wicket. See if we can find an elegant way to make this more
>> > flexible (I'm not in favor of the id based thing someone posted
>> > earlier btw) without breaking the whole world.
>> >
>>
>> We discussed this on ##wicket yesterday.  I asked why we have models
>> on all components and someone pointed out that the main reason was
>> about the detach stuff I believe.  But, couldn't that be solved by
>> having some components that implement something like IModelDriven (or
>> IModelBacked or whatever) and the detach logic could apply to only
>> those components?  Also, someone has pointed out that when they create
>> their own components, they sometimes (such as in Palette) have
>> multiple "models" that they deal with.  Allowing components to name
>> their models what they want would be nice, too.
>>
>> > FWIW, I'm still on the fence when it comes to whether we should go for
>> > a full or partial (models only) implementation of generics, though I'm
>> > leaning towards partial.
>> >
>> > Eelco
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: 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@...

[Jan Kriesten]

hi johan,

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

that would be the consequence with it's tradeoff.

i wouldn't have a problem with that though:

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

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

regards, --- jan.


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

[igor.vaynberg]

why even have an interface? just detach all imodel fields via reflection!

-igor


On Wed, Jun 4, 2008 at 3:37 AM, James Carman <james@...> wrote:

> On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
> <eelco.hillenius@...> wrote:
>>> it all depends, on how and what you're developing.
>>
>> Yeah. I actually use less and less models in the regular way nowadays.
>> I use plenty of panels (the app I work on hardly uses separate pages)
>> that nest other panels in them (typically detail views or dialogs)
>> that reuse models of the parent. But indeed YMMV.
>>
>> Personally, I think the whole generics business exposes that the
>> one-one relation between components and models is flawed. Without
>> generics this isn't much of a problem, just the odd unused member and
>> constructor, but as generics aren't as 'optional' it is all very in
>> your face suddenly.
>>
>> I think on the longer term (post 1.4) we should re-think how models
>> work in Wicket. See if we can find an elegant way to make this more
>> flexible (I'm not in favor of the id based thing someone posted
>> earlier btw) without breaking the whole world.
>>
>
> We discussed this on ##wicket yesterday.  I asked why we have models
> on all components and someone pointed out that the main reason was
> about the detach stuff I believe.  But, couldn't that be solved by
> having some components that implement something like IModelDriven (or
> IModelBacked or whatever) and the detach logic could apply to only
> those components?  Also, someone has pointed out that when they create
> their own components, they sometimes (such as in Palette) have
> multiple "models" that they deal with.  Allowing components to name
> their models what they want would be nice, too.
>
>> FWIW, I'm still on the fence when it comes to whether we should go for
>> a full or partial (models only) implementation of generics, though I'm
>> leaning towards partial.
>>
>> Eelco
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: 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@...

[Johan Compagner]

and if i store it in metadata ;)


On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg <igor.vaynberg@...>
wrote:

> why even have an interface? just detach all imodel fields via reflection!
>
> -igor
>
>
> On Wed, Jun 4, 2008 at 3:37 AM, James Carman <james@...>
> wrote:
> > On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
> > <eelco.hillenius@...> wrote:
> >>> it all depends, on how and what you're developing.
> >>
> >> Yeah. I actually use less and less models in the regular way nowadays.
> >> I use plenty of panels (the app I work on hardly uses separate pages)
> >> that nest other panels in them (typically detail views or dialogs)
> >> that reuse models of the parent. But indeed YMMV.
> >>
> >> Personally, I think the whole generics business exposes that the
> >> one-one relation between components and models is flawed. Without
> >> generics this isn't much of a problem, just the odd unused member and
> >> constructor, but as generics aren't as 'optional' it is all very in
> >> your face suddenly.
> >>
> >> I think on the longer term (post 1.4) we should re-think how models
> >> work in Wicket. See if we can find an elegant way to make this more
> >> flexible (I'm not in favor of the id based thing someone posted
> >> earlier btw) without breaking the whole world.
> >>
> >
> > We discussed this on ##wicket yesterday.  I asked why we have models
> > on all components and someone pointed out that the main reason was
> > about the detach stuff I believe.  But, couldn't that be solved by
> > having some components that implement something like IModelDriven (or
> > IModelBacked or whatever) and the detach logic could apply to only
> > those components?  Also, someone has pointed out that when they create
> > their own components, they sometimes (such as in Palette) have
> > multiple "models" that they deal with.  Allowing components to name
> > their models what they want would be nice, too.
> >
> >> FWIW, I'm still on the fence when it comes to whether we should go for
> >> a full or partial (models only) implementation of generics, though I'm
> >> leaning towards partial.
> >>
> >> Eelco
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: 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@...
>
>