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]
