users, please give us your opinion: what is your take on generics with Wicket

View: New views

20 Messages — Rating Filter: Alert me

< Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14 - 15 | Next >

	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 > <james@...> wrote: > >> You mean like C++? >> >> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <igor.vaynberg@...> wrote: >> >>> indeed. i wouldnt mind if final was the default in java :) >>> >>> -igor >>> >>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>> <martijn.dashorst@...> 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 <brill@...> 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: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> 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: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> >>>> -- >>>> 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: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: users, please give us your opinion: what is your take on generics with Wicket by Jon Laidler :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Eelco Hillenius wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [x] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] .... (anything other than these choices?) 2) How strongly do you feel about your choice above? [x ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For additional commands, e-mail: users-help@wicket.apache.org
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <m.wensveen@...> 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 >> <james@...> wrote: >> >>> You mean like C++? >>> >>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <igor.vaynberg@...> >>> wrote: >>> >>>> indeed. i wouldnt mind if final was the default in java :) >>>> >>>> -igor >>>> >>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>> <martijn.dashorst@...> 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 <brill@...> 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: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> 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: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 igor.vaynberg@... 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 <m.wensveen@...> 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 >>> <james@...> wrote: >>> >>> >>>> You mean like C++? >>>> >>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <igor.vaynberg@...> >>>> wrote: >>>> >>>> >>>>> indeed. i wouldnt mind if final was the default in java :) >>>>> >>>>> -igor >>>>> >>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>> <martijn.dashorst@...> 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 <brill@...> 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: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> 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: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> 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: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <m.wensveen@...> 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 > > igor.vaynberg@... 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 <m.wensveen@...> 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 >>>> <james@...> wrote: >>>> >>>> >>>>> >>>>> You mean like C++? >>>>> >>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>> <igor.vaynberg@...> >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>> >>>>>> -igor >>>>>> >>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>> 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: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <m.wensveen@...> 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 >> >> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>> <james@...> wrote: >>>>> >>>>> >>>>> >>>>>> You mean like C++? >>>>>> >>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>> <igor.vaynberg@...> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>> >>>>>>> -igor >>>>>>> >>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> 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: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <m.wensveen@...> 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 <m.wensveen@...> >> 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 >>> >>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>> <james@...> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> You mean like C++? >>>>>>> >>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>> <igor.vaynberg@...> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>> >>>>>>>> -igor >>>>>>>> >>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <igor.vaynberg@...> 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 <m.wensveen@...> 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 <m.wensveen@...> >>> 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 >>>> >>>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>>> <james@...> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> You mean like C++? >>>>>>>> >>>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>>> <igor.vaynberg@...> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>>> >>>>>>>>> -igor >>>>>>>>> >>>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <igor.vaynberg@...> 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 <m.wensveen@...> 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 <m.wensveen@...> >>>> 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 >>>>> >>>>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>>>> <james@...> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> You mean like C++? >>>>>>>>> >>>>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>>>> <igor.vaynberg@...> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>>>> >>>>>>>>>> -igor >>>>>>>>>> >>>>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Fri, Jun 13, 2008 at 2:44 PM, Matthijs Wensveen <m.wensveen@...> 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 <igor.vaynberg@...> >> 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 <m.wensveen@...> >>> 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 <m.wensveen@...> >>>>> 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 >>>>>> >>>>>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>>>>> <james@...> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> You mean like C++? >>>>>>>>>> >>>>>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>>>>> <igor.vaynberg@...> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>>>>> >>>>>>>>>>> -igor >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>>>>> users-help@... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Eelco Hillenius :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Thu, Jun 12, 2008 at 2:06 PM, Matthijs Wensveen <m.wensveen@...> 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. True, it's been weighing the disadvantages vs the advantages, and so far, ensuring that we wouldn't paint ourselves in the corner too quickly won over flexibility. I think it would be a good idea to take this into consideration with the next major API. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Eelco Hillenius :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message ... > this into consideration with the next major API ... revision (1.5) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Eelco Hillenius :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message > True, it's been weighing the disadvantages vs the advantages, and so > far, ensuring that we wouldn't paint ourselves in the corner too > quickly won over flexibility. To make this 'painless' though, we'd probably need a whole bunch of interfaces. We've looked into moving to a more interface based approach in the past for Wicket, but we concluded that it just got too crazy, increasing the complexity of the API considerably, and had all the disadvantages of interfaces over abstract classes (no guaranteed behavior, everything has to be public and abstract). We might just come to that same conclusion again. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Igor Vaynberg wrote: > On Fri, Jun 13, 2008 at 2:44 PM, Matthijs Wensveen <m.wensveen@...> 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 <igor.vaynberg@...> >>> 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 <m.wensveen@...> >>>> 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 <m.wensveen@...> >>>>>> 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 >>>>>>> >>>>>>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>>>>>> <james@...> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> You mean like C++? >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>>>>>> <igor.vaynberg@...> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>>>>>> >>>>>>>>>>>> -igor >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>>>>>> users-help@... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Eelco Hillenius wrote: >> True, it's been weighing the disadvantages vs the advantages, and so >> far, ensuring that we wouldn't paint ourselves in the corner too >> quickly won over flexibility. >> > > To make this 'painless' though, we'd probably need a whole bunch of > interfaces. We've looked into moving to a more interface based > approach in the past for Wicket, but we concluded that it just got too > crazy, increasing the complexity of the API considerably, and had all > the disadvantages of interfaces over abstract classes (no guaranteed > behavior, everything has to be public and abstract). We might just > come to that same conclusion again. It's good to know that when you reach the same conclusion it is a deliberate one. BTW, interfaces are useful for this, but not a necessity. Or am I the only one thinking that (I seem to be... hmm...). More interfaces mean even more scrolling through the I's in the javadoc, nooooo, lol. Matthijs --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by jwcarman :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Fri, Jun 13, 2008 at 7:02 PM, Matthijs Wensveen <m.wensveen@...> wrote: > It's good to know that when you reach the same conclusion it is a deliberate > one. > BTW, interfaces are useful for this, but not a necessity. Or am I the only > one thinking that (I seem to be... hmm...). More interfaces mean even more > scrolling through the I's in the javadoc, nooooo, lol. Interfaces aren't required to create decorators. Commons proxy (via Javassist and CGLIB) can create decorators for bean classes or interfaces. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message LOL. -igor On 6/13/08, James Carman <james@...> wrote: > On Fri, Jun 13, 2008 at 7:02 PM, Matthijs Wensveen <m.wensveen@...> > wrote: > >> It's good to know that when you reach the same conclusion it is a >> deliberate >> one. >> BTW, interfaces are useful for this, but not a necessity. Or am I the only >> one thinking that (I seem to be... hmm...). More interfaces mean even more >> scrolling through the I's in the javadoc, nooooo, lol. > > Interfaces aren't required to create decorators. Commons proxy (via > Javassist and CGLIB) can create decorators for bean classes or > interfaces. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Eelco Hillenius :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message > It's good to know that when you reach the same conclusion it is a deliberate > one. > BTW, interfaces are useful for this, but not a necessity. Or am I the only > one thinking that No, I agree with you mostly. However, I was trying (back then) to define separate dimensions of components (the fact that they can be rendered is one, and for form components for instance, the fact that they can validate is another). If you have a bunch of useful distinctions like that, you can just decorate them for specific purposes. Maybe. > (I seem to be... hmm...). More interfaces mean even more > scrolling through the I's in the javadoc, nooooo, lol. Indeed, it gets ugly pretty fast. Mixins and interfaces with implementations like scala has would be wonderful here, but alas, we'll have to work with Java. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Martijn Dashorst :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Or with qi4j (http://qi4j.org) Martijn On Sat, Jun 14, 2008 at 5:37 AM, Eelco Hillenius <eelco.hillenius@...> wrote: >> It's good to know that when you reach the same conclusion it is a deliberate >> one. >> BTW, interfaces are useful for this, but not a necessity. Or am I the only >> one thinking that > > No, I agree with you mostly. However, I was trying (back then) to > define separate dimensions of components (the fact that they can be > rendered is one, and for form components for instance, the fact that > they can validate is another). If you have a bunch of useful > distinctions like that, you can just decorate them for specific > purposes. Maybe. > >> (I seem to be... hmm...). More interfaces mean even more >> scrolling through the I's in the javadoc, nooooo, lol. > > Indeed, it gets ugly pretty fast. Mixins and interfaces with > implementations like scala has would be wonderful here, but alas, > we'll have to work with Java. > > Eelco > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > -- 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: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Gwyn :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hmm... (As an aside, I wonder if they mean "pray in the jungle" or "prey in the jungle"? :-)) /Gwyn On Sat, Jun 14, 2008 at 8:23 AM, Martijn Dashorst < martijn.dashorst@...> wrote: > Or with qi4j (http://qi4j.org) > > Martijn > > On Sat, Jun 14, 2008 at 5:37 AM, Eelco Hillenius > <eelco.hillenius@...> wrote: > >> It's good to know that when you reach the same conclusion it is a > deliberate > >> one. > >> BTW, interfaces are useful for this, but not a necessity. Or am I the > only > >> one thinking that > > > > No, I agree with you mostly. However, I was trying (back then) to > > define separate dimensions of components (the fact that they can be > > rendered is one, and for form components for instance, the fact that > > they can validate is another). If you have a bunch of useful > > distinctions like that, you can just decorate them for specific > > purposes. Maybe. > > > >> (I seem to be... hmm...). More interfaces mean even more > >> scrolling through the I's in the javadoc, nooooo, lol. > > > > Indeed, it gets ugly pretty fast. Mixins and interfaces with > > implementations like scala has would be wonderful here, but alas, > > we'll have to work with Java. > > > > Eelco > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe@... > > For additional commands, e-mail: users-help@... > > > > > > > > -- > 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: users-unsubscribe@... > For additional commands, e-mail: users-help@... > >

< Prev | 1 - 2 - 3 - 4 - 5 - 6 - 7 - 8 - 9 - 10 - 11 - 12 - 13 - 14 - 15 | Next >

	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 > <james@...> wrote: > >> You mean like C++? >> >> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <igor.vaynberg@...> wrote: >> >>> indeed. i wouldnt mind if final was the default in java :) >>> >>> -igor >>> >>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>> <martijn.dashorst@...> 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 <brill@...> 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: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> 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: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> >>>> -- >>>> 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: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: users, please give us your opinion: what is your take on generics with Wicket by Jon Laidler :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Eelco Hillenius wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [x] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] .... (anything other than these choices?) 2) How strongly do you feel about your choice above? [x ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org For additional commands, e-mail: users-help@wicket.apache.org
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <m.wensveen@...> 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 >> <james@...> wrote: >> >>> You mean like C++? >>> >>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <igor.vaynberg@...> >>> wrote: >>> >>>> indeed. i wouldnt mind if final was the default in java :) >>>> >>>> -igor >>>> >>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>> <martijn.dashorst@...> 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 <brill@...> 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: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> -- >>>>>>> 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: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> 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: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 igor.vaynberg@... 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 <m.wensveen@...> 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 >>> <james@...> wrote: >>> >>> >>>> You mean like C++? >>>> >>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg <igor.vaynberg@...> >>>> wrote: >>>> >>>> >>>>> indeed. i wouldnt mind if final was the default in java :) >>>>> >>>>> -igor >>>>> >>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>> <martijn.dashorst@...> 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 <brill@...> 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: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> 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: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> -- >>>>>> 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: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <m.wensveen@...> 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 > > igor.vaynberg@... 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 <m.wensveen@...> 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 >>>> <james@...> wrote: >>>> >>>> >>>>> >>>>> You mean like C++? >>>>> >>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>> <igor.vaynberg@...> >>>>> wrote: >>>>> >>>>> >>>>>> >>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>> >>>>>> -igor >>>>>> >>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>> 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: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <m.wensveen@...> 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 >> >> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>> <james@...> wrote: >>>>> >>>>> >>>>> >>>>>> You mean like C++? >>>>>> >>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>> <igor.vaynberg@...> >>>>>> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>> >>>>>>> -igor >>>>>>> >>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> -- >>>>>>>> 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: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <m.wensveen@...> 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 <m.wensveen@...> >> 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 >>> >>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>> <james@...> wrote: >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> You mean like C++? >>>>>>> >>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>> <igor.vaynberg@...> >>>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>> >>>>>>>> -igor >>>>>>>> >>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <igor.vaynberg@...> 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 <m.wensveen@...> 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 <m.wensveen@...> >>> 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 >>>> >>>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>>> <james@...> wrote: >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> You mean like C++? >>>>>>>> >>>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>>> <igor.vaynberg@...> >>>>>>>> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>>> >>>>>>>>> -igor >>>>>>>>> >>>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message 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 <igor.vaynberg@...> 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 <m.wensveen@...> 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 <m.wensveen@...> >>>> 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 >>>>> >>>>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>>>> <james@...> wrote: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> You mean like C++? >>>>>>>>> >>>>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>>>> <igor.vaynberg@...> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>>>> >>>>>>>>>> -igor >>>>>>>>>> >>>>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Fri, Jun 13, 2008 at 2:44 PM, Matthijs Wensveen <m.wensveen@...> 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 <igor.vaynberg@...> >> 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 <m.wensveen@...> >>> 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 <m.wensveen@...> >>>>> 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 >>>>>> >>>>>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>>>>> <james@...> wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> You mean like C++? >>>>>>>>>> >>>>>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>>>>> <igor.vaynberg@...> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>>>>> >>>>>>>>>>> -igor >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>>>>> users-help@... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: users-unsubscribe@... >>>> For additional commands, e-mail: users-help@... >>>> >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Eelco Hillenius :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Thu, Jun 12, 2008 at 2:06 PM, Matthijs Wensveen <m.wensveen@...> 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. True, it's been weighing the disadvantages vs the advantages, and so far, ensuring that we wouldn't paint ourselves in the corner too quickly won over flexibility. I think it would be a good idea to take this into consideration with the next major API. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Eelco Hillenius :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message ... > this into consideration with the next major API ... revision (1.5) --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Eelco Hillenius :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message > True, it's been weighing the disadvantages vs the advantages, and so > far, ensuring that we wouldn't paint ourselves in the corner too > quickly won over flexibility. To make this 'painless' though, we'd probably need a whole bunch of interfaces. We've looked into moving to a more interface based approach in the past for Wicket, but we concluded that it just got too crazy, increasing the complexity of the API considerably, and had all the disadvantages of interfaces over abstract classes (no guaranteed behavior, everything has to be public and abstract). We might just come to that same conclusion again. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Igor Vaynberg wrote: > On Fri, Jun 13, 2008 at 2:44 PM, Matthijs Wensveen <m.wensveen@...> 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 <igor.vaynberg@...> >>> 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 <m.wensveen@...> >>>> 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 <m.wensveen@...> >>>>>> 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 >>>>>>> >>>>>>> igor.vaynberg@... 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 <m.wensveen@...> 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 >>>>>>>>>> <james@...> wrote: >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> You mean like C++? >>>>>>>>>>> >>>>>>>>>>> On Thu, Jun 12, 2008 at 11:35 AM, Igor Vaynberg >>>>>>>>>>> <igor.vaynberg@...> >>>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> indeed. i wouldnt mind if final was the default in java :) >>>>>>>>>>>> >>>>>>>>>>>> -igor >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Jun 12, 2008 at 8:18 AM, Martijn Dashorst >>>>>>>>>>>> <martijn.dashorst@...> 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 <brill@...> >>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>>>>> For additional commands, e-mail: >>>>>>>>>>>>>>>>> users-help@... >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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: users-unsubscribe@... >>>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> --------------------------------------------------------------------- >>>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> --------------------------------------------------------------------- >>>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> --------------------------------------------------------------------- >>>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>>> For additional commands, e-mail: users-help@... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>>> For additional commands, e-mail: users-help@... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>>> For additional commands, e-mail: users-help@... >>>>>> >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscribe@... >>>>> For additional commands, e-mail: users-help@... >>>>> >>>>> >>>>> >>>>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscribe@... >>> For additional commands, e-mail: users-help@... >>> >>> >>> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscribe@... >> For additional commands, e-mail: users-help@... >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Matthijs Wensveen-2 :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Eelco Hillenius wrote: >> True, it's been weighing the disadvantages vs the advantages, and so >> far, ensuring that we wouldn't paint ourselves in the corner too >> quickly won over flexibility. >> > > To make this 'painless' though, we'd probably need a whole bunch of > interfaces. We've looked into moving to a more interface based > approach in the past for Wicket, but we concluded that it just got too > crazy, increasing the complexity of the API considerably, and had all > the disadvantages of interfaces over abstract classes (no guaranteed > behavior, everything has to be public and abstract). We might just > come to that same conclusion again. It's good to know that when you reach the same conclusion it is a deliberate one. BTW, interfaces are useful for this, but not a necessity. Or am I the only one thinking that (I seem to be... hmm...). More interfaces mean even more scrolling through the I's in the javadoc, nooooo, lol. Matthijs --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by jwcarman :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message On Fri, Jun 13, 2008 at 7:02 PM, Matthijs Wensveen <m.wensveen@...> wrote: > It's good to know that when you reach the same conclusion it is a deliberate > one. > BTW, interfaces are useful for this, but not a necessity. Or am I the only > one thinking that (I seem to be... hmm...). More interfaces mean even more > scrolling through the I's in the javadoc, nooooo, lol. Interfaces aren't required to create decorators. Commons proxy (via Javassist and CGLIB) can create decorators for bean classes or interfaces. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by igor.vaynberg :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message LOL. -igor On 6/13/08, James Carman <james@...> wrote: > On Fri, Jun 13, 2008 at 7:02 PM, Matthijs Wensveen <m.wensveen@...> > wrote: > >> It's good to know that when you reach the same conclusion it is a >> deliberate >> one. >> BTW, interfaces are useful for this, but not a necessity. Or am I the only >> one thinking that (I seem to be... hmm...). More interfaces mean even more >> scrolling through the I's in the javadoc, nooooo, lol. > > Interfaces aren't required to create decorators. Commons proxy (via > Javassist and CGLIB) can create decorators for bean classes or > interfaces. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Eelco Hillenius :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message > It's good to know that when you reach the same conclusion it is a deliberate > one. > BTW, interfaces are useful for this, but not a necessity. Or am I the only > one thinking that No, I agree with you mostly. However, I was trying (back then) to define separate dimensions of components (the fact that they can be rendered is one, and for form components for instance, the fact that they can validate is another). If you have a bunch of useful distinctions like that, you can just decorate them for specific purposes. Maybe. > (I seem to be... hmm...). More interfaces mean even more > scrolling through the I's in the javadoc, nooooo, lol. Indeed, it gets ugly pretty fast. Mixins and interfaces with implementations like scala has would be wonderful here, but alas, we'll have to work with Java. Eelco --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Martijn Dashorst :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Or with qi4j (http://qi4j.org) Martijn On Sat, Jun 14, 2008 at 5:37 AM, Eelco Hillenius <eelco.hillenius@...> wrote: >> It's good to know that when you reach the same conclusion it is a deliberate >> one. >> BTW, interfaces are useful for this, but not a necessity. Or am I the only >> one thinking that > > No, I agree with you mostly. However, I was trying (back then) to > define separate dimensions of components (the fact that they can be > rendered is one, and for form components for instance, the fact that > they can validate is another). If you have a bunch of useful > distinctions like that, you can just decorate them for specific > purposes. Maybe. > >> (I seem to be... hmm...). More interfaces mean even more >> scrolling through the I's in the javadoc, nooooo, lol. > > Indeed, it gets ugly pretty fast. Mixins and interfaces with > implementations like scala has would be wonderful here, but alas, > we'll have to work with Java. > > Eelco > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscribe@... > For additional commands, e-mail: users-help@... > > -- 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: users-unsubscribe@... For additional commands, e-mail: users-help@...
	Re: Making Component easier to Generify by Gwyn :: Rate this Message: Reply to Author \| View Threaded \| Show Only this Message Hmm... (As an aside, I wonder if they mean "pray in the jungle" or "prey in the jungle"? :-)) /Gwyn On Sat, Jun 14, 2008 at 8:23 AM, Martijn Dashorst < martijn.dashorst@...> wrote: > Or with qi4j (http://qi4j.org) > > Martijn > > On Sat, Jun 14, 2008 at 5:37 AM, Eelco Hillenius > <eelco.hillenius@...> wrote: > >> It's good to know that when you reach the same conclusion it is a > deliberate > >> one. > >> BTW, interfaces are useful for this, but not a necessity. Or am I the > only > >> one thinking that > > > > No, I agree with you mostly. However, I was trying (back then) to > > define separate dimensions of components (the fact that they can be > > rendered is one, and for form components for instance, the fact that > > they can validate is another). If you have a bunch of useful > > distinctions like that, you can just decorate them for specific > > purposes. Maybe. > > > >> (I seem to be... hmm...). More interfaces mean even more > >> scrolling through the I's in the javadoc, nooooo, lol. > > > > Indeed, it gets ugly pretty fast. Mixins and interfaces with > > implementations like scala has would be wonderful here, but alas, > > we'll have to work with Java. > > > > Eelco > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: users-unsubscribe@... > > For additional commands, e-mail: users-help@... > > > > > > > > -- > 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: users-unsubscribe@... > For additional commands, e-mail: users-help@... > >

users, please give us your opinion: what is your take on generics with Wicket

Re: Making Component easier to Generify

Re: users, please give us your opinion: what is your take on generics with Wicket

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify

Re: Making Component easier to Generify