look at the java example. notice Window is an interface. eg you cant do: add(new DecoratedComponent(someOtherComponent));
-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]
