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? > 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. -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]
