generics

[Matej Knopp]

On Thu, Jul 3, 2008 at 10:02 AM, Eelco Hillenius
<eelco.hillenius@...> wrote:

> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <matej.knopp@...> wrote:
>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>> Wouldn't that feel more like crippled?
>> The default model slot doesn't take any runtime space when you don't
>> use it, property would. And removing four methods from component will
>> hardly make it much lighter.
>
> I wasn't just thinking about models though. *I* would like us to go
> through the API when we start on 1.5 and remove anything that isn't
> necessary. Remove all the the deprecations and convenience methods
> that have (easy) alternatives. All the while keeping an easy upgrade
> path in mind of course.

Okay. Big +1 here of course.,

-Matej

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

[Eelco Hillenius]

>> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <matej.knopp@...> wrote:
>>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>>> Wouldn't that feel more like crippled?
>>> The default model slot doesn't take any runtime space when you don't
>>> use it, property would. And removing four methods from component will
>>> hardly make it much lighter.
>>
> Big +1 on that :)

That's a +1 on your own reply... cheater! ;-)

Eelco

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

[Eelco Hillenius]

On Thu, Jul 3, 2008 at 9:46 AM, Eelco Hillenius
<eelco.hillenius@...> wrote:

>>> On Thu, Jul 3, 2008 at 12:47 AM, Matej Knopp <matej.knopp@...> wrote:
>>>> Ligther? Does it meen with no Compund and ComponentAssignedModel?
>>>> Wouldn't that feel more like crippled?
>>>> The default model slot doesn't take any runtime space when you don't
>>>> use it, property would. And removing four methods from component will
>>>> hardly make it much lighter.
>>>
>> Big +1 on that :)
>
> That's a +1 on your own reply... cheater! ;-)

Like Martijn said.... ugh I need to learn to read the rest of the
thread before replying first!

Eelco

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

[Matthijs Wensveen-2]

Matej Knopp wrote:

> On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <matej.knopp@...> wrote:
>  
>>> And there is some functionality in there that Wicket might
>>> be better without. For example, onModelChanged / Changing
>>> things become tricky when you share the same model between
>>> different instances. And when using setModelObject() with an
>>> object that is equal to the current model object, but a
>>> different instance (such as a Hibernate-persisted object
>>> bound to the correct session), you have to either do
>>> getModel().setObject() or change the model comparator.
>>>
>>>      
>> setModelObject isn't the best idea IMHO. Models should support some
>> kind of state change notifications, we might want to improve that for
>> 1.5, though it probably wouldn't be very easy to do.
>>    
> Well, we can hardly detect change of propertypromodels unless we pull
> and compare the value every time...
>  

Better state change notifications would be a huge improvement IMO
because that way components could add themselves to AjaxRequestTarget
when needed. Currently all Ajax functionality requires Ajaxified
components to know about each other and when they should be displayed.
Some kind of even mechanism as described in
https://issues.apache.org/jira/browse/WICKET-1312 would definitely help,
but a model-driven approach would be even better.

I was thinking to support this using annotations and aspects and the
likes, but I haven't had the time to create a proof of concept.

Matthijs

PS. Thread subject has become little different than thread content :)

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


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

[Johan Compagner]

There are many state things in a component. Wicket itself has only a
few like model/visibile/enable. But a developer could add many many
more.

In our project this is easily handled by our components. Every
component knows when it is changed, what ever it is and then a visitor
adds them to ajax. We have a fixed set of components so its not a big
problem.

On 7/4/08, Matthijs Wensveen <m.wensveen@...> wrote:

> Matej Knopp wrote:
>> On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <matej.knopp@...> wrote:
>>
>>>> And there is some functionality in there that Wicket might
>>>> be better without. For example, onModelChanged / Changing
>>>> things become tricky when you share the same model between
>>>> different instances. And when using setModelObject() with an
>>>> object that is equal to the current model object, but a
>>>> different instance (such as a Hibernate-persisted object
>>>> bound to the correct session), you have to either do
>>>> getModel().setObject() or change the model comparator.
>>>>
>>>>
>>> setModelObject isn't the best idea IMHO. Models should support some
>>> kind of state change notifications, we might want to improve that for
>>> 1.5, though it probably wouldn't be very easy to do.
>>>
>> Well, we can hardly detect change of propertypromodels unless we pull
>> and compare the value every time...
>>
>
> Better state change notifications would be a huge improvement IMO
> because that way components could add themselves to AjaxRequestTarget
> when needed. Currently all Ajax functionality requires Ajaxified
> components to know about each other and when they should be displayed.
> Some kind of even mechanism as described in
> https://issues.apache.org/jira/browse/WICKET-1312 would definitely help,
> but a model-driven approach would be even better.
>
> I was thinking to support this using annotations and aspects and the
> likes, but I haven't had the time to create a proof of concept.
>
> Matthijs
>
> PS. Thread subject has become little different than thread content :)
>
> --
> Matthijs Wensveen
> Func. Internet Integration
> W http://www.func.nl
> T [phone]
> F [phone]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

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

[Matthijs Wensveen-2]

How do you cope with deeply nested model properties? For example:

public class PersonViewer extends Component<Person> {
..
}

some other component does:
person.getOrders().get(0).setAmount(0); // first order for free (as in beer)

Matthijs

Johan Compagner wrote:

> There are many state things in a component. Wicket itself has only a
> few like model/visibile/enable. But a developer could add many many
> more.
>
> In our project this is easily handled by our components. Every
> component knows when it is changed, what ever it is and then a visitor
> adds them to ajax. We have a fixed set of components so its not a big
> problem.
>
> On 7/4/08, Matthijs Wensveen <m.wensveen@...> wrote:
>  
>> Matej Knopp wrote:
>>    
>>> On Thu, Jul 3, 2008 at 9:51 AM, Matej Knopp <matej.knopp@...> wrote:
>>>
>>>      
>>>>> And there is some functionality in there that Wicket might
>>>>> be better without. For example, onModelChanged / Changing
>>>>> things become tricky when you share the same model between
>>>>> different instances. And when using setModelObject() with an
>>>>> object that is equal to the current model object, but a
>>>>> different instance (such as a Hibernate-persisted object
>>>>> bound to the correct session), you have to either do
>>>>> getModel().setObject() or change the model comparator.
>>>>>
>>>>>
>>>>>          
>>>> setModelObject isn't the best idea IMHO. Models should support some
>>>> kind of state change notifications, we might want to improve that for
>>>> 1.5, though it probably wouldn't be very easy to do.
>>>>
>>>>        
>>> Well, we can hardly detect change of propertypromodels unless we pull
>>> and compare the value every time...
>>>
>>>      
>> Better state change notifications would be a huge improvement IMO
>> because that way components could add themselves to AjaxRequestTarget
>> when needed. Currently all Ajax functionality requires Ajaxified
>> components to know about each other and when they should be displayed.
>> Some kind of even mechanism as described in
>> https://issues.apache.org/jira/browse/WICKET-1312 would definitely help,
>> but a model-driven approach would be even better.
>>
>> I was thinking to support this using annotations and aspects and the
>> likes, but I haven't had the time to create a proof of concept.
>>
>> Matthijs
>>
>> PS. Thread subject has become little different than thread content :)
>>
>> --
>> Matthijs Wensveen
>> Func. Internet Integration
>> W http://www.func.nl
>> T [phone]
>> F [phone]
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>  

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


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

[Timo Rantalaiho]

On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
> How do you cope with deeply nested model properties? For example:
>
> public class PersonViewer extends Component<Person> {
> ..
> }
>
> some other component does:
> person.getOrders().get(0).setAmount(0); // first order for free (as in beer)

I have no idea of Johan's project, but normally you just
edit an object in one place at a time, and PersonViewer
would be a read-only component with a model that always
pulls the freshest version of the person it is displaying
from the database.

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

[Timo Rantalaiho]

On Thu, 03 Jul 2008, Matej Knopp wrote:
> I'm gonna be -1 on removing model utility methods and default model
> slot from component until you suggest a clean and transparent way to
> support
> - compound (inherited) models
> - component assigned models
> - automatic detachment

Fair enough, let's see what we can come up with :)

I was thinking that most of that stuff could be achieved by
moving more logic to the model classes. Some things such as
the add(new Label("name")); for
CompoundPropertyModel-component children could be tricky to
get working though.

Anyway, I agree that now our focus must be on getting 1.4
out of the door -- the reason this came up was just that I
was thinking out loud whether the plans for 1.5 have
implications on what to add in 1.4.

Automatic detachment for all IModel fields of a component
would be great (and the easiest to do of those I suppose).

> From component where? ComponentUtil? Component has a very strong and
> complicated contract. There are lot of methods in component, but there
> are reasons for it. There are parts like rendering though that might
> need to be cleaned up.

Definitely not to a utility class with static methods :)
Maybe some of the responsibilities can be moved to different
other classes, such as ComponentTag and MarkupStream. But
let's see that when working on 1.5.

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

[Matthijs Wensveen-2]

Timo Rantalaiho wrote:

> On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
>  
>> How do you cope with deeply nested model properties? For example:
>>
>> public class PersonViewer extends Component<Person> {
>> ..
>> }
>>
>> some other component does:
>> person.getOrders().get(0).setAmount(0); // first order for free (as in beer)
>>    
>
> I have no idea of Johan's project, but normally you just
> edit an object in one place at a time, and PersonViewer
> would be a read-only component with a model that always
> pulls the freshest version of the person it is displaying
> from the database.
>
> Best wishes,
> Timo
>
>  

The thing is that when using Ajax you have to specifically add
PersonViewer to the AjaxRequestTarget when 'some other component'
modifies the Person object. The problem is that 'some other component'
might not even know about or have access to PersonViewer (maybe it's a
3rd-party component). OnModelChanged does not work in this case, because
there is no call to setModelObject, just to some setter of the Person
object.

While Ajax does very nice things to the GUI, it kinda messes up the
model-driven (as in wicket model) approach to gui development. That is
why I was thinking about some aspect-oriented solution to let components
know about model updates, even when they keep a reference to the same
object.

Matthijs

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


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

[Johan Compagner]

thats just a listener interface for example PropertyChangeListener (but you
can make it more specific interface)
Just make a base model that has add/removePropertyChangeListener and let
your components listen to that

johan


On Mon, Jul 7, 2008 at 8:28 AM, Matthijs Wensveen <m.wensveen@...>
wrote:

> Timo Rantalaiho wrote:
>
>> On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
>>
>>
>>> How do you cope with deeply nested model properties? For example:
>>>
>>> public class PersonViewer extends Component<Person> {
>>> ..
>>> }
>>>
>>> some other component does:
>>> person.getOrders().get(0).setAmount(0); // first order for free (as in
>>> beer)
>>>
>>>
>>
>> I have no idea of Johan's project, but normally you just edit an object in
>> one place at a time, and PersonViewer would be a read-only component with a
>> model that always pulls the freshest version of the person it is displaying
>> from the database.
>>
>> Best wishes,
>> Timo
>>
>>
>>
> The thing is that when using Ajax you have to specifically add PersonViewer
> to the AjaxRequestTarget when 'some other component' modifies the Person
> object. The problem is that 'some other component' might not even know about
> or have access to PersonViewer (maybe it's a 3rd-party component).
> OnModelChanged does not work in this case, because there is no call to
> setModelObject, just to some setter of the Person object.
>
> While Ajax does very nice things to the GUI, it kinda messes up the
> model-driven (as in wicket model) approach to gui development. That is why I
> was thinking about some aspect-oriented solution to let components know
> about model updates, even when they keep a reference to the same object.
>
> Matthijs
>
> --
> Matthijs Wensveen
> Func. Internet Integration
> W http://www.func.nl
> T [phone]
> F [phone]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Matthijs Wensveen-2]

I always find using PropertyChangeSupport and ProperyChangeListener is a
lot of work and kinda pollutes your code. But it is a solution. Maybe a
combination of ProperyChangeListener and AOP could be made to reduce the
required boilerplate code.

Matthijs

Johan Compagner wrote:

> thats just a listener interface for example PropertyChangeListener (but you
> can make it more specific interface)
> Just make a base model that has add/removePropertyChangeListener and let
> your components listen to that
>
> johan
>
>
> On Mon, Jul 7, 2008 at 8:28 AM, Matthijs Wensveen <m.wensveen@...>
> wrote:
>
>  
>> Timo Rantalaiho wrote:
>>
>>    
>>> On Fri, 04 Jul 2008, Matthijs Wensveen wrote:
>>>
>>>
>>>      
>>>> How do you cope with deeply nested model properties? For example:
>>>>
>>>> public class PersonViewer extends Component<Person> {
>>>> ..
>>>> }
>>>>
>>>> some other component does:
>>>> person.getOrders().get(0).setAmount(0); // first order for free (as in
>>>> beer)
>>>>
>>>>
>>>>        
>>> I have no idea of Johan's project, but normally you just edit an object in
>>> one place at a time, and PersonViewer would be a read-only component with a
>>> model that always pulls the freshest version of the person it is displaying
>>> from the database.
>>>
>>> Best wishes,
>>> Timo
>>>
>>>
>>>
>>>      
>> The thing is that when using Ajax you have to specifically add PersonViewer
>> to the AjaxRequestTarget when 'some other component' modifies the Person
>> object. The problem is that 'some other component' might not even know about
>> or have access to PersonViewer (maybe it's a 3rd-party component).
>> OnModelChanged does not work in this case, because there is no call to
>> setModelObject, just to some setter of the Person object.
>>
>> While Ajax does very nice things to the GUI, it kinda messes up the
>> model-driven (as in wicket model) approach to gui development. That is why I
>> was thinking about some aspect-oriented solution to let components know
>> about model updates, even when they keep a reference to the same object.
>>
>> Matthijs
>>
>> --
>> Matthijs Wensveen
>> Func. Internet Integration
>> W http://www.func.nl
>> T [phone]
>> F [phone]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>>
>>    
>
>  

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


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

[David N. Arnold]

See this article

http://weblogs.java.net/blog/rbair/archive/2006/05/the_unknown_jav.html

for a clean solution to this problem.  Essentially, you can grab a
class "JavaBean" from the SwingX project and extend it.

Of course if you're already extending another class it doesn't really
help you out...


On Tue, Jul 8, 2008 at 5:58 AM, Matthijs Wensveen <m.wensveen@...> wrote:
> I always find using PropertyChangeSupport and ProperyChangeListener is a lot
> of work and kinda pollutes your code. But it is a solution. Maybe a
> combination of ProperyChangeListener and AOP could be made to reduce the
> required boilerplate code.
>
> Matthijs
>

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

[Maarten Bosteels]

Haven't yet tried it myself, but this project seems like a big help when you
have to support ProperyChangeListener etc :

https://bean-properties.dev.java.net/10things.html

Maarten

On Tue, Jul 8, 2008 at 2:03 PM, David N. Arnold <david.n.arnold@...>
wrote:

> See this article
>
> http://weblogs.java.net/blog/rbair/archive/2006/05/the_unknown_jav.html
>
> for a clean solution to this problem.  Essentially, you can grab a
> class "JavaBean" from the SwingX project and extend it.
>
> Of course if you're already extending another class it doesn't really
> help you out...
>
>
> On Tue, Jul 8, 2008 at 5:58 AM, Matthijs Wensveen <m.wensveen@...>
> wrote:
> > I always find using PropertyChangeSupport and ProperyChangeListener is a
> lot
> > of work and kinda pollutes your code. But it is a solution. Maybe a
> > combination of ProperyChangeListener and AOP could be made to reduce the
> > required boilerplate code.
> >
> > Matthijs
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

[Timo Rantalaiho]

On Mon, 07 Jul 2008, Matthijs Wensveen wrote:
> The thing is that when using Ajax you have to specifically add
> PersonViewer to the AjaxRequestTarget when 'some other component'
> modifies the Person object. The problem is that 'some other component'
> might not even know about or have access to PersonViewer (maybe it's a
> 3rd-party component). OnModelChanged does not work in this case, because
> there is no call to setModelObject, just to some setter of the Person
> object.

Yep, in our current project we use the WICKET-1312
"broadcaster" approach to solve this. This means that the
logic of which component needs to be repainted when
something happens is in the UI components. (The domain logic
itself we try to put in the domain objects.)

So in our model, the other component modifying the Person
object would broadcast a PersonModifiedEvent to all
PersonModificationReceiver components, who could then act
accordingly (typically add themselves to the Ajax request
target). There's not a lot of automagical intelligence
there, but we have found this way clear and effective. All
relationships are "static" on component class level and
navigable in the IDE. The proliferation of events and
receivers must be watched out for though.

> While Ajax does very nice things to the GUI, it kinda messes up the
> model-driven (as in wicket model) approach to gui development. That is
> why I was thinking about some aspect-oriented solution to let components
> know about model updates, even when they keep a reference to the same
> object.

That's true. It's a pity that for now, Java AOP solutions
are still a bit invasive (AFAIK, if you know of some really
neat and transparent implementation without -javaagents or
special compilers or some such nuisance, I'd be glad to hear
:)).

We tried sharing models and making them more intelligent and
models sending events to registered listeners and whatnot
dead chickens before arriving at the current
broadcast/receiver approach. When the components are
"physically" far away from each other, sharing the model or
handling registration and deregistration can get hairy. And
to avoid memory leaks, removing the listeners when
components are being replaced (e.g. repeater children
recreated) should be taken care of carefully in a
traditional event-listener mechanism.

However, more experimentation is definitely needed on this,
and I'd be very interested on hearing any experiences and
ideas!  It seems that ajax will be around for some more
years, whether we like it or not, so best to make the best
out of it :)

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

[Matthijs Wensveen-2]

Timo Rantalaiho wrote:

> On Mon, 07 Jul 2008, Matthijs Wensveen wrote:
>  
>> The thing is that when using Ajax you have to specifically add
>> PersonViewer to the AjaxRequestTarget when 'some other component'
>> modifies the Person object. The problem is that 'some other component'
>> might not even know about or have access to PersonViewer (maybe it's a
>> 3rd-party component). OnModelChanged does not work in this case, because
>> there is no call to setModelObject, just to some setter of the Person
>> object.
>>    
>
> Yep, in our current project we use the WICKET-1312
> "broadcaster" approach to solve this. This means that the
> logic of which component needs to be repainted when
> something happens is in the UI components. (The domain logic
> itself we try to put in the domain objects.)
>
> So in our model, the other component modifying the Person
> object would broadcast a PersonModifiedEvent to all
> PersonModificationReceiver components, who could then act
> accordingly (typically add themselves to the Ajax request
> target). There's not a lot of automagical intelligence
> there, but we have found this way clear and effective. All
> relationships are "static" on component class level and
> navigable in the IDE. The proliferation of events and
> receivers must be watched out for though.
>  

I knew about WICKET-1312, but hadn't thought of broadcasting domain
object typed events, just things like onClick and such which gives too
little information. Thanks for the eyeopener!

>  
>> While Ajax does very nice things to the GUI, it kinda messes up the
>> model-driven (as in wicket model) approach to gui development. That is
>> why I was thinking about some aspect-oriented solution to let components
>> know about model updates, even when they keep a reference to the same
>> object.
>>    
>
> That's true. It's a pity that for now, Java AOP solutions
> are still a bit invasive (AFAIK, if you know of some really
> neat and transparent implementation without -javaagents or
> special compilers or some such nuisance, I'd be glad to hear
> :)).
>
> We tried sharing models and making them more intelligent and
> models sending events to registered listeners and whatnot
> dead chickens before arriving at the current
> broadcast/receiver approach. When the components are
> "physically" far away from each other, sharing the model or
> handling registration and deregistration can get hairy. And
> to avoid memory leaks, removing the listeners when
> components are being replaced (e.g. repeater children
> recreated) should be taken care of carefully in a
> traditional event-listener mechanism.
>  

Maybe listeners could be registered using weak references so that the
objects are still garbage collected even when the listener is still alive.
> However, more experimentation is definitely needed on this,
> and I'd be very interested on hearing any experiences and
> ideas!  It seems that ajax will be around for some more
> years, whether we like it or not, so best to make the best
> out of it :)
>
> Best wishes, Timo
>  

Matthijs

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


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

[Craig McIlwee]

personally i am still in favor of going with the m2 way of doing things where Component is generic, but from the looks of the discussion i think i may be in the minority here.  this kinda surprises me though because as i read the original generic discussion it sounded like most people supported Component<T>.

igor.vaynberg wrote:

basically we feel this is a much cleaner way then what is 1.4m2. this
is a call for confirmation/discussion from our user base.

1) i'm not sure i agree with this.  i don't feel that just adding <Void> to components that don't need their models makes things messy.  i'd much rather have the option to use generics whenever i need than to create extra classes such as the 'GenericPanel', etc that have been mentioned.  in fact i think its alot messier to create more classes and to start changing method names (getDefaultModel, etc) and then adding getModel to the classes that do use generics.

2) the wicket web site now suggests the following code for generic components:

@SuppressWarnings("unchecked")
public final T getModelObject()
{
        return (T)getDefaultModelObject();
}

... but isn't the purpose of adding generic support to wicket to prevent the need for unchecked casts?  if we now have to place unchecked casts into our code then we lose out on the strong type checking that generics are supposed to provide.  its not hard to imagine a case where one part of someone's code calls setDefaultModelObject with the wrong type, and then later another part of the code calls getModelObject and hits a class cast exception.

3) the Component class has several methods that return 'this' to allow for method chaining.  the problem here is that the generic components don't override these methods with covariant returns, so if i do something like formComponent.setVersioned(false).moreMethodCalls().chainedTogether()  then those chained methods can't use models because we've upcast our component to something that doesn't have generic support.  i guess the solution would be to put these calls on separate lines, but it seems like a bit of a hassle (i'm probably just being picky tho)

- craig

[Brill Pappin]

I think you are *not* in the minority, but a lot of the dissenters  
piped in last minute in a big flood so to some it might look that way.

However, It may actually be valuable the way they are doing it now, so  
I'm reserving judgement until I can sit down and port my latest  
project to it... and check out how well it works.
The moment I have to do a cast, I'll consider it a sign that it needs  
more work.

- Brill Pappin

On 14-Jul-08, at 10:17 AM, Craig McIlwee wrote:

>
> personally i am still in favor of going with the m2 way of doing  
> things where
> Component is generic, but from the looks of the discussion i think i  
> may be
> in the minority here.  this kinda surprises me though because as i  
> read the
> original generic discussion it sounded like most people supported
> Component<T>.
>
>
> igor.vaynberg wrote:
>>
>> basically we feel this is a much cleaner way then what is 1.4m2. this
>> is a call for confirmation/discussion from our user base.
>>
>
> 1) i'm not sure i agree with this.  i don't feel that just adding  
> <Void> to
> components that don't need their models makes things messy.  i'd  
> much rather
> have the option to use generics whenever i need than to create extra  
> classes
> such as the 'GenericPanel', etc that have been mentioned.  in fact i  
> think
> its alot messier to create more classes and to start changing method  
> names
> (getDefaultModel, etc) and then adding getModel to the classes that  
> do use
> generics.
>
> 2) the wicket web site now suggests the following code for generic
> components:
>
> @SuppressWarnings("unchecked")
> public final T getModelObject()
> {
>        return (T)getDefaultModelObject();
> }
>
> ... but isn't the purpose of adding generic support to wicket to  
> prevent the
> need for unchecked casts?  if we now have to place unchecked casts  
> into our
> code then we lose out on the strong type checking that generics are  
> supposed
> to provide.  its not hard to imagine a case where one part of  
> someone's code
> calls setDefaultModelObject with the wrong type, and then later  
> another part
> of the code calls getModelObject and hits a class cast exception.
>
> 3) the Component class has several methods that return 'this' to  
> allow for
> method chaining.  the problem here is that the generic components  
> don't
> override these methods with covariant returns, so if i do something  
> like
> formComponent
> .setVersioned(false).moreMethodCalls().chainedTogether()  then
> those chained methods can't use models because we've upcast our  
> component to
> something that doesn't have generic support.  i guess the solution  
> would be
> to put these calls on separate lines, but it seems like a bit of a  
> hassle
> (i'm probably just being picky tho)
>
> - craig
> --
> View this message in context: http://www.nabble.com/generics-tp18083910p18444866.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>

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

[Martijn Dashorst]

On Mon, Jul 14, 2008 at 5:03 PM, Brill Pappin <brill@...> wrote:
> I think you are *not* in the minority, but a lot of the dissenters piped in
> last minute in a big flood so to some it might look that way.

I think this is a baseless statement: both sides have been very vocal.
In any case this will not be a majority vote unless there is a 1-99%
split, but even then: the core committers have the final say and it is
their responsibility to move the project forward in the way they deem
to be in the best interest of the framework. This doesn't say the
wicket committers don't value your input, nor won't take it into
account (lots of double negatives). In other words: we *do* value your
input and feedback, and will take it into account, but the ultimate
responsibility lies with the core committers.

> However, It may actually be valuable the way they are doing it now, so I'm
> reserving judgement until I can sit down and port my latest project to it...
> and check out how well it works.

This is what we ask, so thanks and please provide feedback!

> The moment I have to do a cast, I'll consider it a sign that it needs more
> work.

This is what we propose: when you come across a point where generics
should be added, give us a note. We will take it into consideration,
just as we do with removing "final" in our code base.

Martijn

> On 14-Jul-08, at 10:17 AM, Craig McIlwee wrote:
>
>>
>> personally i am still in favor of going with the m2 way of doing things
>> where
>> Component is generic, but from the looks of the discussion i think i may
>> be
>> in the minority here.  this kinda surprises me though because as i read
>> the
>> original generic discussion it sounded like most people supported
>> Component<T>.
>>
>>
>> igor.vaynberg wrote:
>>>
>>> basically we feel this is a much cleaner way then what is 1.4m2. this
>>> is a call for confirmation/discussion from our user base.
>>>
>>
>> 1) i'm not sure i agree with this.  i don't feel that just adding <Void>
>> to
>> components that don't need their models makes things messy.  i'd much
>> rather
>> have the option to use generics whenever i need than to create extra
>> classes
>> such as the 'GenericPanel', etc that have been mentioned.  in fact i think
>> its alot messier to create more classes and to start changing method names
>> (getDefaultModel, etc) and then adding getModel to the classes that do use
>> generics.
>>
>> 2) the wicket web site now suggests the following code for generic
>> components:
>>
>> @SuppressWarnings("unchecked")
>> public final T getModelObject()
>> {
>>       return (T)getDefaultModelObject();
>> }
>>
>> ... but isn't the purpose of adding generic support to wicket to prevent
>> the
>> need for unchecked casts?  if we now have to place unchecked casts into
>> our
>> code then we lose out on the strong type checking that generics are
>> supposed
>> to provide.  its not hard to imagine a case where one part of someone's
>> code
>> calls setDefaultModelObject with the wrong type, and then later another
>> part
>> of the code calls getModelObject and hits a class cast exception.
>>
>> 3) the Component class has several methods that return 'this' to allow for
>> method chaining.  the problem here is that the generic components don't
>> override these methods with covariant returns, so if i do something like
>> formComponent.setVersioned(false).moreMethodCalls().chainedTogether()
>>  then
>> those chained methods can't use models because we've upcast our component
>> to
>> something that doesn't have generic support.  i guess the solution would
>> be
>> to put these calls on separate lines, but it seems like a bit of a hassle
>> (i'm probably just being picky tho)
>>
>> - craig
>> --
>> View this message in context:
>> http://www.nabble.com/generics-tp18083910p18444866.html
>> Sent from the Wicket - User mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@...
>> For additional commands, e-mail: users-help@...
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@...
> For additional commands, e-mail: users-help@...
>
>

--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Apache Wicket 1.3.4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.

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

[Brill Pappin]

On 14-Jul-08, at 11:24 AM, Martijn Dashorst wrote:

> On Mon, Jul 14, 2008 at 5:03 PM, Brill Pappin <brill@...> wrote:
>> I think you are *not* in the minority, but a lot of the dissenters  
>> piped in
>> last minute in a big flood so to some it might look that way.
>
> I think this is a baseless statement: both sides have been very vocal.
> In any case this will not be a majority vote unless there is a 1-99%
> split, but even then: the core committers have the final say and it is
> their responsibility to move the project forward in the way they deem
> to be in the best interest of the framework. This doesn't say the
> wicket committers don't value your input, nor won't take it into
> account (lots of double negatives). In other words: we *do* value your
> input and feedback, and will take it into account, but the ultimate
> responsibility lies with the core committers.

I'd say that WIcket *is a product*, and as such the consumers of that  
product have the final say. It's up to the "core committers" to do the  
best job they can to make sure their "consumers" are getting what they  
need... just because it's an OS project that we don't have to buy,  
doesn't mean that the project doesn't depend on people using it.

That said, I think that you guys have done some good work and have  
produced a good product with or without the generics.

- Brill Pappin

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

[John Patterson]

Craig McIlwee wrote:

2) the wicket web site now suggests the following code for generic components:

@SuppressWarnings("unchecked")
public final T getModelObject()
{
        return (T)getDefaultModelObject();
}

I am just starting to use the new form and it struck me as a little strange that getModel() and its friends are not a part of any interface or abstract class.