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