Igor Vaynberg wrote:
On Fri, Jun 13, 2008 at 2:44 PM, Matthijs Wensveen <[EMAIL PROTECTED]> wrote:
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.
decorator classes in the onjava article do not perform method
delegation across all methods in JComponent, therefore its not a
decorator by your own definition?
It's still is a decorator, but I agree it does not do exactly as I
thought a proper decorator should do. The delegation is still there, but
it is hidden because the wrapped class is added as a child to the
decorator. The super.xxx calls take care of calling the needed methods
on the wrapped class. But this only works for hierarchies like swing.
Hmm.. if I were very puristic, I might not call this decoration at all,
in the OO-sense of the pattern. This really just takes a component and
puts it somewhere else. It *is* transparent to the (api) user however.
It doesn't need to know or care this has happened, so in that sense it
is a decorator.
Also, I did say: "It is not entirely impossible to decorate a class with
final methods, you just can't delegate the final methods" . So, "my
definition" does not enforce that every method should be delegated. You
may read the words "Implementing each and every method of a class and
delegating to another class is indeed what is needed" as "Implementing
each and every method of a class and delegating to another class is
indeed what is *usually / generally* needed" :)
Also look at the C++ example.
C++ doesn't have interfaces. So, maybe this is a ui decorator as well...?
actually c++ does have interfaces, they are modeled as "pure virtual"
classes, which is what the c++ Window class in the wikipedia article
is.
Okay, but then abstract classes in java are interfaces as well :). You
said decoration *only* works with interfaces, and there was no way for
me to know that your notion of the term interface included classes as
well (because then what are we even arguing about :) )
Hm, anyway, let's drop the almost religious fanaticism. We could argue
about the definition of the term decorator all year, presumably, but
whatever it is called, what I want can't be done in wicket because of
some final methods that are in the way. The Link.onClick problem is
still unsolved.
Matthijs
-igor
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]
---------------------------------------------------------------------
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]
