I am not aware of a distinction between software decorator and ui
decorator. But seeing as wicket is a ui framework, I'll go with ui
decorator. Border looks somewhat like a decorator, but since it does not
wrap another component, it is not. Also Border needs different markup
than the component it 'decorates' which makes it nontransparent, which
is kind of the point of decorators. I like to thing of decorators as
classes that piggyback behavior on existing instances.
Implementing each and every method of a class and delegating to another
class is indeed what is needed, but is certainly not insanity. If you
use eclipse you can do this easily by adding a member field of a certain
type, right-click it and select Source > Generate Delegate Methods. When
decorating a class is common and intended use of that class, an API
usually supplies a SomethingSomethingDecorator class (extends /
implements SomethingSomething) that delegates every method by default.
You'd then only have to subclass that class.
Calling super in methods that only implement an interface as in your
reply is just not possible (does not even compile), you need to subclass
in order to be able to do that.
To return to the final method argument. It is not entirely impossible to
decorate a class with final methods, you just can't delegate the final
methods. An important one to be able to delegate in wicket is
MarkupContainer.add. Otherwise you'd break the hierarchy with a
decorated MarkupContainer.
By the way, the article I supplied and the article on wikipedia do just
the same thing. If you look at VerticalScrollBarDecorator.draw you'll
see that it delegates the method to the wrapped Window. Also look at the
C++ example. C++ doesn't have interfaces. So, maybe this is a ui
decorator as well...? At the end of the article there is a list of other
design patterns from the GoF book, unfortunately I couldn't find
anything about the software decorator pattern you mentioned (also
googled it without avail).
So, okay, let's end this discussion for Godwin's sake.
I really do want to know how to add behaviour in a transparent way to an
existing Link's onClick method. Using Behavior or some other means. AOP
is an option but feels hacky just to do this (pointcuts should generally
match more than one joinpoint). Event listeners are another (but I won't
dare begin that discussion again).
Best regards,
Matthijs
Igor Vaynberg wrote:
looked over the article. what they do is a ui decorator, it is not the
software decorator pattern. there is no method delegation to the child
component. what they create is a composite, you can do the same thing
in wicket with a Border.
-igor
On Thu, Jun 12, 2008 at 9:55 PM, Igor Vaynberg <[EMAIL PROTECTED]> wrote:
right. so when you would do it with a class you will actually have to
rewire all the methods to forward to the delegate instead of calling
super. that is pure insanity and does not make any sense when methods
hold logic. that is why it works with an interface, no logic for you
to override and forward to the delegate, only the message dispatch
itself. sure, technically you can do it even with a concrete class,
but you can also do a lot of other things that dont make sense.
-igor
On Thu, Jun 12, 2008 at 5:54 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
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 <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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
<[EMAIL PROTECTED]> wrote:
You mean like C++?
On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg
<[EMAIL PROTECTED]>
wrote:
indeed. i wouldnt mind if final was the default in java :)
-igor
On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst
<[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
