... unless you feel IBehavior is no longer cohesive and needs to be
abandoned for that reason, or that it, or your new "Behavior" class
itself, should become an extension of multiple smaller interfaces that
more sensibly split, group and name the full range of
responsibilities, and if you are not proposing to widen or narrow the
API/functionality expected (of "Behavior") by Component, wouldn't
public abstract class Behavior implements IBehavior{...}
be not only less disruptive but also not unnecessarily limit
design/implementation options open to app developers?
For example,
// this would need to be rewritten
final IBehavior myBehevior = new AjaxEventBehavior("onmouseover"){...}
Beyond the stated relinquishment of proxies and mixins, this also
removes some implementation options when "adapt"ing to IBehavior (you
could still use delegation instead of implementation inheritance),
which may or may not be a smart practice, but why would Wicket take
responsibility for enforcing such judgement?
Other similar limitations would also be introduced, possibly without sufficient
compensation (1 less type to maintain?!)
For example,
// although this looks like a mixin too, the intention
// here is to adapt C to IBehavior's interface
class A extends C implements IBehavior{...}
Regards - Cemal
jWeekend
Training, Consulting, Development
http://jWeekend.com
On 27 November 2010 03:07, Igor Vaynberg <igor.vaynb...@gmail.com> wrote:
> Vote is now closed with 4 binding +1 votes. I will work on implementing this
> soon.
>
> -igor
>
> On Nov 26, 2010 11:47 AM, "Martin Grigorov" <mgrigo...@apache.org> wrote:
>
> +1
>
> On Wed, Nov 24, 2010 at 3:26 PM, Johan Compagner <jcompag...@gmail.com
>>wrote:
>
>
>> +1
>>
>> On Wed, Nov 24, 2010 at 03:22, Igor Vaynberg <igor.vaynb...@gmail.com>
>> wrote:
>> > the ib...
>
