|
»
»
« Return to Thread: users, please give us your opinion: what is your take on generics with Wicket
Re: Making Component easier to Generify
by Matthijs Wensveen-2
::
Rate this Message:
Igor Vaynberg wrote:
> look at the java example. notice Window is an interface.
>
Yeah, but that's just because it's good practice to use the interface
when there is one. Notice that the actually decorated class is a new
SimpleWindow() in DecoratedWindowTest. Window might as well have been an
abstract class, or even a concrete one. The idea is that the contract of
the class you wrap is maintained, if that is an interface your decorator
implements that, when it's a class your decorator extends it. Same idea.
Of course, interfaces are cleaner and you can even decorate more then
one interface when you want to, but decorating a class is not uncommon
practice (at least where I come from).
Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html
> eg you cant do: add(new DecoratedComponent(someOtherComponent));
>
No, because component has final methods that you can't override so you
can't delegate to them (that whas my point), but not because you can't
decorate a class.
Matthijs.
PS. If you insist on that you can only decorate an interface, I'll call
it wrap-extend or something :)
> -igor
>
> On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <m.wensveen@...> wrote:
>
>> Why would the decorator design pattern only work with interfaces? Maybe
>> we're talking about two different this here? (I'm talking about this one:
>> http://en.wikipedia.org/wiki/Decorator_pattern)
>>
>> I can see why behaviors were introduced. A simple example: a factory method
>> creates a link. In my subclass I want the same link with the same onClick
>> behavior but I also want "hello" to be outputted to System.out. How would I
>> go about doing this with a Behavior? I couldn't figure it out... (which
>> isn't saying it's impossible).
>>
>> Matthijs
>>
>> igor.vaynberg@... wrote:
>>
>>> decorators only work with interfaces, component class is not. This is
>>> part of the reason why we have behaviors
>>>
>>> -igor
>>>
>>> On 6/12/08, Matthijs Wensveen <m.wensveen@...> wrote:
>>>
>>>
>>>> Some useful design patterns like Decorator don't work with final
>>>> methods. Wicket components sometimes have overridable factory methods
>>>> for child components. The decorator pattern could be very useful here,
>>>> because you'd be able to decorate the original component with some extra
>>>> functionality (Link.onClick for example). Unfortunately this doesn't
>>>> work because some methods are final.
>>>>
>>>> Matthijs
>>>>
>>>> Igor Vaynberg wrote:
>>>>
>>>>
>>>>> i mean generally, for methods, fields, and func args :) most of this
>>>>> stuff can stay final, but people dont bother doing it because its
>>>>> extra typing.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Thu, Jun 12, 2008 at 8:38 AM, James Carman
>>>>> <james@...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> You mean like C++?
>>>>>>
>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg
>>>>>> <igor.vaynberg@...>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> indeed. i wouldnt mind if final was the default in java :)
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
>>>>>>> <martijn.dashorst@...> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Without the use of final wicket would not have made it this far.
>>>>>>>>
>>>>>>>> Martijn
>>>>>>>>
>>>>>>>> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <brill@...>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I understand the reasoning, however I think "best practice" can be
>>>>>>>>> debated.
>>>>>>>>> To use your example Swing allows the user to override quite a bit,
>>>>>>>>> and
>>>>>>>>> it
>>>>>>>>> doesn't make any (or very few) assumptions on what should and should
>>>>>>>>> not be
>>>>>>>>> done.
>>>>>>>>>
>>>>>>>>> I don't like API's that assume I'm an idiot and prevent me from
>>>>>>>>> manipulating
>>>>>>>>> them how I see fit. If I cause a bug that I have to deal with, thats
>>>>>>>>> *my*
>>>>>>>>> problem to resolve.
>>>>>>>>>
>>>>>>>>> In my book (and I'm not the only one) excessive use of final is an
>>>>>>>>> anti-pattern.
>>>>>>>>>
>>>>>>>>> - Brill Pappin
>>>>>>>>>
>>>>>>>>> On 12-Jun-08, at 10:01 AM, cowwoc wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Brill,
>>>>>>>>>>
>>>>>>>>>> This is actually an API "best practice". Classes fall into two
>>>>>>>>>> categories:
>>>>>>>>>> ones designed for subclassing, and ones designed to be final. The
>>>>>>>>>> same
>>>>>>>>>> goes
>>>>>>>>>> for methods. Swing is full of examples of what goes wrong when
>>>>>>>>>> people
>>>>>>>>>> override methods in classes that haven't been designed with
>>>>>>>>>> subclassing in
>>>>>>>>>> mind.
>>>>>>>>>>
>>>>>>>>>> Gili
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Brill Pappin wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> on removing the finals
>>>>>>>>>>>
>>>>>>>>>>> The final members are the worst thing I've had to deal with in
>>>>>>>>>>> Wicket
>>>>>>>>>>> so far.
>>>>>>>>>>> Although I understand that there may be a reason for them, they
>>>>>>>>>>> are
>>>>>>>>>>> more a hinderance than anything else and seem to be trying to
>>>>>>>>>>> "protect
>>>>>>>>>>> users from themselves".
>>>>>>>>>>>
>>>>>>>>>>> - Brill Pappin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 12-Jun-08, at 1:03 AM, cowwoc wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Have you considered moving from subclassing to composition in
>>>>>>>>>>>> Wicket
>>>>>>>>>>>> using
>>>>>>>>>>>> Callable<T>?
>>>>>>>>>>>>
>>>>>>>>>>>> Currently it is quite common for developers to subclass a
>>>>>>>>>>>> component
>>>>>>>>>>>> in order
>>>>>>>>>>>> to override isVisible() and other properties. I am proposing that
>>>>>>>>>>>> instead
>>>>>>>>>>>> the component classes become final and properties may only be set
>>>>>>>>>>>> using
>>>>>>>>>>>> setter methods. The setter methods would take Callable<T> instead
>>>>>>>>>>>> of
>>>>>>>>>>>> T, so
>>>>>>>>>>>> for example setVisible(boolean) would become
>>>>>>>>>>>> setVisible(Callable<Boolean>)
>>>>>>>>>>>>
>>>>>>>>>>>> The benefit of this approach is that you could introduce static
>>>>>>>>>>>> factory
>>>>>>>>>>>> methods to the Wicket components which would make them much
>>>>>>>>>>>> easier
>>>>>>>>>>>> to use in
>>>>>>>>>>>> their Generic form. You could then introduce various helper
>>>>>>>>>>>> classes
>>>>>>>>>>>> to
>>>>>>>>>>>> create Callable<T> for constant values, such as
>>>>>>>>>>>> Callable.valueOf(true) would
>>>>>>>>>>>> return a Callable<Boolean> that always returns true.
>>>>>>>>>>>> --
>>>>>>>>>>>> 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-tp17589984p17792488.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@...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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-tp17589984p17800710.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.3 is released
>>>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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@...
> look at the java example. notice Window is an interface.
>
Yeah, but that's just because it's good practice to use the interface
when there is one. Notice that the actually decorated class is a new
SimpleWindow() in DecoratedWindowTest. Window might as well have been an
abstract class, or even a concrete one. The idea is that the contract of
the class you wrap is maintained, if that is an interface your decorator
implements that, when it's a class your decorator extends it. Same idea.
Of course, interfaces are cleaner and you can even decorate more then
one interface when you want to, but decorating a class is not uncommon
practice (at least where I come from).
Example: http://www.onjava.com/pub/a/onjava/2003/02/05/decorator.html
> eg you cant do: add(new DecoratedComponent(someOtherComponent));
>
No, because component has final methods that you can't override so you
can't delegate to them (that whas my point), but not because you can't
decorate a class.
Matthijs.
PS. If you insist on that you can only decorate an interface, I'll call
it wrap-extend or something :)
> -igor
>
> On Thu, Jun 12, 2008 at 5:05 PM, Matthijs Wensveen <m.wensveen@...> wrote:
>
>> Why would the decorator design pattern only work with interfaces? Maybe
>> we're talking about two different this here? (I'm talking about this one:
>> http://en.wikipedia.org/wiki/Decorator_pattern)
>>
>> I can see why behaviors were introduced. A simple example: a factory method
>> creates a link. In my subclass I want the same link with the same onClick
>> behavior but I also want "hello" to be outputted to System.out. How would I
>> go about doing this with a Behavior? I couldn't figure it out... (which
>> isn't saying it's impossible).
>>
>> Matthijs
>>
>> igor.vaynberg@... wrote:
>>
>>> decorators only work with interfaces, component class is not. This is
>>> part of the reason why we have behaviors
>>>
>>> -igor
>>>
>>> On 6/12/08, Matthijs Wensveen <m.wensveen@...> wrote:
>>>
>>>
>>>> Some useful design patterns like Decorator don't work with final
>>>> methods. Wicket components sometimes have overridable factory methods
>>>> for child components. The decorator pattern could be very useful here,
>>>> because you'd be able to decorate the original component with some extra
>>>> functionality (Link.onClick for example). Unfortunately this doesn't
>>>> work because some methods are final.
>>>>
>>>> Matthijs
>>>>
>>>> Igor Vaynberg wrote:
>>>>
>>>>
>>>>> i mean generally, for methods, fields, and func args :) most of this
>>>>> stuff can stay final, but people dont bother doing it because its
>>>>> extra typing.
>>>>>
>>>>> -igor
>>>>>
>>>>> On Thu, Jun 12, 2008 at 8:38 AM, James Carman
>>>>> <james@...> wrote:
>>>>>
>>>>>
>>>>>
>>>>>> You mean like C++?
>>>>>>
>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg
>>>>>> <igor.vaynberg@...>
>>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> indeed. i wouldnt mind if final was the default in java :)
>>>>>>>
>>>>>>> -igor
>>>>>>>
>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
>>>>>>> <martijn.dashorst@...> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>> Without the use of final wicket would not have made it this far.
>>>>>>>>
>>>>>>>> Martijn
>>>>>>>>
>>>>>>>> On Thu, Jun 12, 2008 at 5:08 PM, Brill Pappin <brill@...>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> I understand the reasoning, however I think "best practice" can be
>>>>>>>>> debated.
>>>>>>>>> To use your example Swing allows the user to override quite a bit,
>>>>>>>>> and
>>>>>>>>> it
>>>>>>>>> doesn't make any (or very few) assumptions on what should and should
>>>>>>>>> not be
>>>>>>>>> done.
>>>>>>>>>
>>>>>>>>> I don't like API's that assume I'm an idiot and prevent me from
>>>>>>>>> manipulating
>>>>>>>>> them how I see fit. If I cause a bug that I have to deal with, thats
>>>>>>>>> *my*
>>>>>>>>> problem to resolve.
>>>>>>>>>
>>>>>>>>> In my book (and I'm not the only one) excessive use of final is an
>>>>>>>>> anti-pattern.
>>>>>>>>>
>>>>>>>>> - Brill Pappin
>>>>>>>>>
>>>>>>>>> On 12-Jun-08, at 10:01 AM, cowwoc wrote:
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Brill,
>>>>>>>>>>
>>>>>>>>>> This is actually an API "best practice". Classes fall into two
>>>>>>>>>> categories:
>>>>>>>>>> ones designed for subclassing, and ones designed to be final. The
>>>>>>>>>> same
>>>>>>>>>> goes
>>>>>>>>>> for methods. Swing is full of examples of what goes wrong when
>>>>>>>>>> people
>>>>>>>>>> override methods in classes that haven't been designed with
>>>>>>>>>> subclassing in
>>>>>>>>>> mind.
>>>>>>>>>>
>>>>>>>>>> Gili
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Brill Pappin wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>> on removing the finals
>>>>>>>>>>>
>>>>>>>>>>> The final members are the worst thing I've had to deal with in
>>>>>>>>>>> Wicket
>>>>>>>>>>> so far.
>>>>>>>>>>> Although I understand that there may be a reason for them, they
>>>>>>>>>>> are
>>>>>>>>>>> more a hinderance than anything else and seem to be trying to
>>>>>>>>>>> "protect
>>>>>>>>>>> users from themselves".
>>>>>>>>>>>
>>>>>>>>>>> - Brill Pappin
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 12-Jun-08, at 1:03 AM, cowwoc wrote:
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>> Have you considered moving from subclassing to composition in
>>>>>>>>>>>> Wicket
>>>>>>>>>>>> using
>>>>>>>>>>>> Callable<T>?
>>>>>>>>>>>>
>>>>>>>>>>>> Currently it is quite common for developers to subclass a
>>>>>>>>>>>> component
>>>>>>>>>>>> in order
>>>>>>>>>>>> to override isVisible() and other properties. I am proposing that
>>>>>>>>>>>> instead
>>>>>>>>>>>> the component classes become final and properties may only be set
>>>>>>>>>>>> using
>>>>>>>>>>>> setter methods. The setter methods would take Callable<T> instead
>>>>>>>>>>>> of
>>>>>>>>>>>> T, so
>>>>>>>>>>>> for example setVisible(boolean) would become
>>>>>>>>>>>> setVisible(Callable<Boolean>)
>>>>>>>>>>>>
>>>>>>>>>>>> The benefit of this approach is that you could introduce static
>>>>>>>>>>>> factory
>>>>>>>>>>>> methods to the Wicket components which would make them much
>>>>>>>>>>>> easier
>>>>>>>>>>>> to use in
>>>>>>>>>>>> their Generic form. You could then introduce various helper
>>>>>>>>>>>> classes
>>>>>>>>>>>> to
>>>>>>>>>>>> create Callable<T> for constant values, such as
>>>>>>>>>>>> Callable.valueOf(true) would
>>>>>>>>>>>> return a Callable<Boolean> that always returns true.
>>>>>>>>>>>> --
>>>>>>>>>>>> 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-tp17589984p17792488.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@...
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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-tp17589984p17800710.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.3 is released
>>>>>>>> Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3
>>>>>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> 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@...
« Return to Thread: users, please give us your opinion: what is your take on generics with Wicket
| Free embeddable forum powered by Nabble | Forum Help |
