You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Jonathan Locke <jo...@gmail.com> on 2007/05/13 17:13:58 UTC
Code Freeze for RC?
I'd like to propose that we either wrap this up immediately (next
day or two) or simply not fix this for 1.3. We need to get an RC
out there as soon as possible.
Eelco Hillenius wrote:
>
> We have a bit of a stalemate currently in how we'll support validators
> that are or contribute behaviors.
>
> First, why would we want such behaviors? It is to enable validators to
> influence what is rendered so that they can e.g. set a maxlength
> attribute, add client side javascript validation, or even add ajax
> validation (or a combination of these).
>
> For example:
>
> private static class MaxLengthValidator extends
> StringValidator.MaximumLengthValidator
> implements
> IBehaviorProvider
> {
> public MaxLengthValidator(int maximum)
> {
> super(maximum);
> }
>
> public IBehavior newValidationBehavior(Component component)
> {
> if (component instanceof AbstractTextComponent)
> {
> return new SimpleAttributeModifier("maxlength",
> String.valueOf(getMaximum()));
> }
> return null;
> }
> }
>
> The current implementation is based on interface IBehaviorProvider:
>
> /**
> * Validator that provides a behavior, e.g. for rendering client-side or
> ajax
> * validation. This interface can be implemented by either
> * {@link IValidator validators} or {@link IFormValidator form
> validators}.
> */
> public interface IBehaviorProvider extends IClusterable
> {
> /**
> * Gets behavior for validation. This method is called right after the
> * validator is added to a form or form component. The resulting behavior
> * will be added to the component. Note that after the behavior is added,
> it
> * will just lead its own life; this method will not be invoked anymore.
> *
> * @param component
> * component currently using the validator
> * @return The behavior, which can be used for rendering e.g. javascript
> or
> * ajax validation. If this returns null, it will be ignored.
> */
> IBehavior newValidationBehavior(Component component);
> }
>
> which is an optional interface your validators can implement if they
> want to contribute such behaviors.
>
> Now Igor in particular has a problem with this solution as he likes
> the alternative (which I actually implemented at first, but didn't
> commit) where you can simply code classes that are both a validator
> and a behavior (implement IValidator or IFormValidator and IBehavior).
>
> The technical issue with that is that we have an add method for both,
> while they have a different hierarchy, so unless you do a hard cast,
> it's not going to work. And even if you do a hard cast, behaviors and
> validators are currently stored in their own structures, so either the
> add methods would have to be aware that a behavior can also be a
> validator (detail: validators currently are only known by form
> components, so add(IBehavior) would have to do some instanceof
> checking on itself to get this working) and that a validator can be a
> behavior in the add(I(Form)Validator) method.
>
> A way to fix this is to create a common interface (in my
> implementation I called this IComponentFacet) for IBehavior and
> IValidator and have one add method. In the mechanism I implemented,
> facets were stored in the same structure (so the validators field in
> FormComponent was removed) and it worked with a lookup method like
> getFacets(Class).
>
> The problem with this though is that once we start thinking in this
> direction, it opens up a whole new range of questions. For instance,
> what happens when people add validators to non-form components? Is
> 'detachable' or 'onBefore/AfterRender' really only something for
> behaviors? What kind of mixing and matching can we expect people to
> try in the future? I guess my largest problem is that I don't have a
> great feeling about this mixing conceptually. I think in a future
> version of Wicket, we might improve components by decoupling parts of
> it so that you can assemble the parts you need. If and only if that
> would really be worth the increased complexity of the API that comes
> with such a change. However, I'm afraid that by supporting a kind-of
> mixin like a combined validator and behavior is a step in that
> direction, but it's too soon, half baked (like Jonathan stated on IRC,
> we probably first need a full fledged event system in components if we
> want to support components by composition).
>
> The elegance of the current solution is that imho it doesn't have any
> conceptual blur. Validators are still validators, but by implementing
> IBehaviorProvider they can additionally *contribute* a behavior, which
> is very different from *being* (IS-A) a behavior at the same time. It
> is easy to implement (it's in svn right now, and I'm not worried for
> one second this addition is limiting the way we can grow our API as
> long as we keep this simple). Nice about the current solution is also
> that it is easy to let your validator return different behaviors, e.g.
> depending on the (type of) component it is coupled to. You can achieve
> the same by using delegation in the validator/behavior you'd implement
> otherwise, but imo, that's much less elegant and basically forces you
> to either implement this pattern over and over again, or extend a base
> class which limits your options. Not to mention that in the IS-A
> scenario you'd have to be aware that if something can be an attribute
> modifier or/ and an ajax behavior, you'd have to implement interface
> IBehaviorListener or be ok with implementing an abstract ajax behavior
> even if you would just need the attribute modifier for one occassion.
>
> I guess my point is made. I'll back off for a bit and see what other
> people have to say about this. Anyone's opinions are welcome, and core
> developers, please contribute so that we can make this decision in
> consensus.
>
> Cheers,
>
> Eelco
>
>
--
View this message in context: http://www.nabble.com/poll%3A-validators-and-behaviors-combined...-contribute-or-IS-A--tf3727027.html#a10455689
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Code Freeze for RC?
Posted by Jonathan Locke <jo...@gmail.com>.
please vote then on the vote i just posted.
Ryan Sonnek-2 wrote:
>
> Although I'm not a core developer, since I was involved in bringing
> this topic up, i'll just throw my 2 cents out there.
>
> This is definately not a showstopper for me, and I would rather see
> wicket 1.3 get out the door. This issue is more of a long term design
> decision and shouldn't be rushed.
>
> On 5/13/07, Jonathan Locke <jo...@gmail.com> wrote:
>>
>>
>> I'd like to propose that we either wrap this up immediately (next
>> day or two) or simply not fix this for 1.3. We need to get an RC
>> out there as soon as possible.
>>
>>
>> Eelco Hillenius wrote:
>> >
>> > We have a bit of a stalemate currently in how we'll support validators
>> > that are or contribute behaviors.
>> >
>> > First, why would we want such behaviors? It is to enable validators to
>> > influence what is rendered so that they can e.g. set a maxlength
>> > attribute, add client side javascript validation, or even add ajax
>> > validation (or a combination of these).
>> >
>> > For example:
>> >
>> > private static class MaxLengthValidator extends
>> > StringValidator.MaximumLengthValidator
>> > implements
>> > IBehaviorProvider
>> > {
>> > public MaxLengthValidator(int maximum)
>> > {
>> > super(maximum);
>> > }
>> >
>> > public IBehavior newValidationBehavior(Component
>> component)
>> > {
>> > if (component instanceof AbstractTextComponent)
>> > {
>> > return new
>> SimpleAttributeModifier("maxlength",
>> > String.valueOf(getMaximum()));
>> > }
>> > return null;
>> > }
>> > }
>> >
>> > The current implementation is based on interface IBehaviorProvider:
>> >
>> > /**
>> > * Validator that provides a behavior, e.g. for rendering client-side
>> or
>> > ajax
>> > * validation. This interface can be implemented by either
>> > * {@link IValidator validators} or {@link IFormValidator form
>> > validators}.
>> > */
>> > public interface IBehaviorProvider extends IClusterable
>> > {
>> > /**
>> > * Gets behavior for validation. This method is called right
>> after the
>> > * validator is added to a form or form component. The resulting
>> behavior
>> > * will be added to the component. Note that after the behavior
>> is added,
>> > it
>> > * will just lead its own life; this method will not be invoked
>> anymore.
>> > *
>> > * @param component
>> > * component currently using the validator
>> > * @return The behavior, which can be used for rendering e.g.
>> javascript
>> > or
>> > * ajax validation. If this returns null, it will be
>> ignored.
>> > */
>> > IBehavior newValidationBehavior(Component component);
>> > }
>> >
>> > which is an optional interface your validators can implement if they
>> > want to contribute such behaviors.
>> >
>> > Now Igor in particular has a problem with this solution as he likes
>> > the alternative (which I actually implemented at first, but didn't
>> > commit) where you can simply code classes that are both a validator
>> > and a behavior (implement IValidator or IFormValidator and IBehavior).
>> >
>> > The technical issue with that is that we have an add method for both,
>> > while they have a different hierarchy, so unless you do a hard cast,
>> > it's not going to work. And even if you do a hard cast, behaviors and
>> > validators are currently stored in their own structures, so either the
>> > add methods would have to be aware that a behavior can also be a
>> > validator (detail: validators currently are only known by form
>> > components, so add(IBehavior) would have to do some instanceof
>> > checking on itself to get this working) and that a validator can be a
>> > behavior in the add(I(Form)Validator) method.
>> >
>> > A way to fix this is to create a common interface (in my
>> > implementation I called this IComponentFacet) for IBehavior and
>> > IValidator and have one add method. In the mechanism I implemented,
>> > facets were stored in the same structure (so the validators field in
>> > FormComponent was removed) and it worked with a lookup method like
>> > getFacets(Class).
>> >
>> > The problem with this though is that once we start thinking in this
>> > direction, it opens up a whole new range of questions. For instance,
>> > what happens when people add validators to non-form components? Is
>> > 'detachable' or 'onBefore/AfterRender' really only something for
>> > behaviors? What kind of mixing and matching can we expect people to
>> > try in the future? I guess my largest problem is that I don't have a
>> > great feeling about this mixing conceptually. I think in a future
>> > version of Wicket, we might improve components by decoupling parts of
>> > it so that you can assemble the parts you need. If and only if that
>> > would really be worth the increased complexity of the API that comes
>> > with such a change. However, I'm afraid that by supporting a kind-of
>> > mixin like a combined validator and behavior is a step in that
>> > direction, but it's too soon, half baked (like Jonathan stated on IRC,
>> > we probably first need a full fledged event system in components if we
>> > want to support components by composition).
>> >
>> > The elegance of the current solution is that imho it doesn't have any
>> > conceptual blur. Validators are still validators, but by implementing
>> > IBehaviorProvider they can additionally *contribute* a behavior, which
>> > is very different from *being* (IS-A) a behavior at the same time. It
>> > is easy to implement (it's in svn right now, and I'm not worried for
>> > one second this addition is limiting the way we can grow our API as
>> > long as we keep this simple). Nice about the current solution is also
>> > that it is easy to let your validator return different behaviors, e.g.
>> > depending on the (type of) component it is coupled to. You can achieve
>> > the same by using delegation in the validator/behavior you'd implement
>> > otherwise, but imo, that's much less elegant and basically forces you
>> > to either implement this pattern over and over again, or extend a base
>> > class which limits your options. Not to mention that in the IS-A
>> > scenario you'd have to be aware that if something can be an attribute
>> > modifier or/ and an ajax behavior, you'd have to implement interface
>> > IBehaviorListener or be ok with implementing an abstract ajax behavior
>> > even if you would just need the attribute modifier for one occassion.
>> >
>> > I guess my point is made. I'll back off for a bit and see what other
>> > people have to say about this. Anyone's opinions are welcome, and core
>> > developers, please contribute so that we can make this decision in
>> > consensus.
>> >
>> > Cheers,
>> >
>> > Eelco
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/poll%3A-validators-and-behaviors-combined...-contribute-or-IS-A--tf3727027.html#a10455689
>> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>>
>>
>
>
--
View this message in context: http://www.nabble.com/poll%3A-validators-and-behaviors-combined...-contribute-or-IS-A--tf3727027.html#a10457175
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Re: Code Freeze for RC?
Posted by Ryan Sonnek <ry...@gmail.com>.
Although I'm not a core developer, since I was involved in bringing
this topic up, i'll just throw my 2 cents out there.
This is definately not a showstopper for me, and I would rather see
wicket 1.3 get out the door. This issue is more of a long term design
decision and shouldn't be rushed.
On 5/13/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> I'd like to propose that we either wrap this up immediately (next
> day or two) or simply not fix this for 1.3. We need to get an RC
> out there as soon as possible.
>
>
> Eelco Hillenius wrote:
> >
> > We have a bit of a stalemate currently in how we'll support validators
> > that are or contribute behaviors.
> >
> > First, why would we want such behaviors? It is to enable validators to
> > influence what is rendered so that they can e.g. set a maxlength
> > attribute, add client side javascript validation, or even add ajax
> > validation (or a combination of these).
> >
> > For example:
> >
> > private static class MaxLengthValidator extends
> > StringValidator.MaximumLengthValidator
> > implements
> > IBehaviorProvider
> > {
> > public MaxLengthValidator(int maximum)
> > {
> > super(maximum);
> > }
> >
> > public IBehavior newValidationBehavior(Component component)
> > {
> > if (component instanceof AbstractTextComponent)
> > {
> > return new SimpleAttributeModifier("maxlength",
> > String.valueOf(getMaximum()));
> > }
> > return null;
> > }
> > }
> >
> > The current implementation is based on interface IBehaviorProvider:
> >
> > /**
> > * Validator that provides a behavior, e.g. for rendering client-side or
> > ajax
> > * validation. This interface can be implemented by either
> > * {@link IValidator validators} or {@link IFormValidator form
> > validators}.
> > */
> > public interface IBehaviorProvider extends IClusterable
> > {
> > /**
> > * Gets behavior for validation. This method is called right after the
> > * validator is added to a form or form component. The resulting behavior
> > * will be added to the component. Note that after the behavior is added,
> > it
> > * will just lead its own life; this method will not be invoked anymore.
> > *
> > * @param component
> > * component currently using the validator
> > * @return The behavior, which can be used for rendering e.g. javascript
> > or
> > * ajax validation. If this returns null, it will be ignored.
> > */
> > IBehavior newValidationBehavior(Component component);
> > }
> >
> > which is an optional interface your validators can implement if they
> > want to contribute such behaviors.
> >
> > Now Igor in particular has a problem with this solution as he likes
> > the alternative (which I actually implemented at first, but didn't
> > commit) where you can simply code classes that are both a validator
> > and a behavior (implement IValidator or IFormValidator and IBehavior).
> >
> > The technical issue with that is that we have an add method for both,
> > while they have a different hierarchy, so unless you do a hard cast,
> > it's not going to work. And even if you do a hard cast, behaviors and
> > validators are currently stored in their own structures, so either the
> > add methods would have to be aware that a behavior can also be a
> > validator (detail: validators currently are only known by form
> > components, so add(IBehavior) would have to do some instanceof
> > checking on itself to get this working) and that a validator can be a
> > behavior in the add(I(Form)Validator) method.
> >
> > A way to fix this is to create a common interface (in my
> > implementation I called this IComponentFacet) for IBehavior and
> > IValidator and have one add method. In the mechanism I implemented,
> > facets were stored in the same structure (so the validators field in
> > FormComponent was removed) and it worked with a lookup method like
> > getFacets(Class).
> >
> > The problem with this though is that once we start thinking in this
> > direction, it opens up a whole new range of questions. For instance,
> > what happens when people add validators to non-form components? Is
> > 'detachable' or 'onBefore/AfterRender' really only something for
> > behaviors? What kind of mixing and matching can we expect people to
> > try in the future? I guess my largest problem is that I don't have a
> > great feeling about this mixing conceptually. I think in a future
> > version of Wicket, we might improve components by decoupling parts of
> > it so that you can assemble the parts you need. If and only if that
> > would really be worth the increased complexity of the API that comes
> > with such a change. However, I'm afraid that by supporting a kind-of
> > mixin like a combined validator and behavior is a step in that
> > direction, but it's too soon, half baked (like Jonathan stated on IRC,
> > we probably first need a full fledged event system in components if we
> > want to support components by composition).
> >
> > The elegance of the current solution is that imho it doesn't have any
> > conceptual blur. Validators are still validators, but by implementing
> > IBehaviorProvider they can additionally *contribute* a behavior, which
> > is very different from *being* (IS-A) a behavior at the same time. It
> > is easy to implement (it's in svn right now, and I'm not worried for
> > one second this addition is limiting the way we can grow our API as
> > long as we keep this simple). Nice about the current solution is also
> > that it is easy to let your validator return different behaviors, e.g.
> > depending on the (type of) component it is coupled to. You can achieve
> > the same by using delegation in the validator/behavior you'd implement
> > otherwise, but imo, that's much less elegant and basically forces you
> > to either implement this pattern over and over again, or extend a base
> > class which limits your options. Not to mention that in the IS-A
> > scenario you'd have to be aware that if something can be an attribute
> > modifier or/ and an ajax behavior, you'd have to implement interface
> > IBehaviorListener or be ok with implementing an abstract ajax behavior
> > even if you would just need the attribute modifier for one occassion.
> >
> > I guess my point is made. I'll back off for a bit and see what other
> > people have to say about this. Anyone's opinions are welcome, and core
> > developers, please contribute so that we can make this decision in
> > consensus.
> >
> > Cheers,
> >
> > Eelco
> >
> >
>
> --
> View this message in context: http://www.nabble.com/poll%3A-validators-and-behaviors-combined...-contribute-or-IS-A--tf3727027.html#a10455689
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>