You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wicket.apache.org by Eelco Hillenius <ee...@gmail.com> on 2007/05/11 13:55:24 UTC
poll: validators and behaviors combined... contribute or IS-A?
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
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.
>
>
Code Freeze for RC?
Posted by Jonathan Locke <jo...@gmail.com>.
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: poll: validators and behaviors combined... contribute or IS-A?
Posted by Igor Vaynberg <ig...@gmail.com>.
huh?
-igor
On 5/11/07, Bruno Borges <br...@gmail.com> wrote:
>
> To follow with onAttach/onDetach (I don't remember if these has -ed)
>
> --
> Bruno Borges
> Summa Technologies Inc.
> www.summa-tech.com
> (48) 8404-1300
> (11) 3055-2060
>
> On 5/11/07, Igor Vaynberg <ig...@gmail.com> wrote:
> >
> > so why is it onadded() here and bind() in ibehavior?
> >
> > -igor
> >
> >
> > On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > I guess sitting back is not my strongest point :)
> > >
> > > I just committed a variant of Al's idea:
> > >
> > > /**
> > > * Optional interface for validators ({@link IValidator} and
> > > * {@link IFormValidator}) that can react to validators being added to
> a
> > > * component.
> > > * <p>
> > > * Implementation note: currently we keep this case simple stupid
> > > non-generic.
> > > * In future versions we may revisit this and support removal events
> > (WHEN
> > > * removal of validators is ever allowed, which justifies it's own
> > > discussion).
> > > * Also, we may look at whether this is a common event to support for
> > > behaviors
> > > * as well. This raises additional questions that need to be answered,
> > > hence
> > > * we'll start by supporting just the use case when validators are
> added
> > to
> > > * forms or form components.
> > > * </p>
> > > */
> > > public interface IValidatorAddListener extends IClusterable
> > > {
> > > /**
> > > * Called right after a validator was added to a {@link Form}
> or
> > > * {@link FormComponent}. A common use case for implementing
> > this
> > > interface
> > > * is for validators to add behaviors to implement client side
> > > validation
> > > * capabilities, e.g. through JavaScript, Ajax or just by
> adding
> > a
> > > simple
> > > * attribute modifier that sets a maxlength attribute.
> > > *
> > > * @param component
> > > * component to which the validator was just added.
> > > */
> > > void onAdded(Component component);
> > > }
> > >
> > > for which you can have an implementation like:
> > >
> > > private static class MaxLengthValidator extends
> > > StringValidator.MaximumLengthValidator
> > > implements
> > > IValidatorAddListener
> > > {
> > > public MaxLengthValidator(int maximum)
> > > {
> > > super(maximum);
> > > }
> > >
> > > public void onAdded(Component component)
> > > {
> > > if (component instanceof
> AbstractTextComponent)
> > > {
> > > component.add(new
> > > SimpleAttributeModifier("maxlength",
> > > String.valueOf(getMaximum())));
> > > }
> > > }
> > > }
> > >
> > >
> > > Eelco
> > >
> > >
> > > On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > Well, if you feel strongly about this, maybe it is time to open
> > > > another discussion about this specifically or (maybe better as we're
> > > > having to digest lots of traffic to start with) a JIRA feature
> > > > request.
> > > >
> > > > Eelco
> > > >
> > > > On 5/11/07, Bruno Borges <br...@gmail.com> wrote:
> > > > > Because Wicket is component based... :) We actually reuse
> components
> > > and
> > > > > somewhere we want to disable validators. For example: chained
> > > components
> > > > > where one component if selected, must disable another component's
> > > validator.
> > > > >
> > > > > --
> > > > > Bruno Borges
> > > > > Summa Technologies Inc.
> > > > > www.summa-tech.com
> > > > > (48) 8404-1300
> > > > > (11) 3055-2060
> > > > >
> > > > > On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > > >
> > > > > > > How about enabled/disabled validators (and their behaviors) ?
> > This
> > > way,
> > > > > > no
> > > > > > > counting down is needed and when validatores are disabled,
> they
> > > > > > propagate
> > > > > > > this state to behaviors. Removing validators is strange to me,
> > but
> > > > > > disabling
> > > > > > > them for a while, I think this is more reasonable.
> > > > > >
> > > > > > Maybe. Again would be more in line with behaviors. But now the
> > > million
> > > > > > dollar question: for what use case? When would you actually ever
> > > need
> > > > > > to remove or disable a validator? And *if* you would ever need
> > such
> > > an
> > > > > > exotic case, why does Wicket have to do this for you and why
> don't
> > > we
> > > > > > tell people to just make this part of the way they implement
> their
> > > > > > validation method?
> > > > > >
> > > > > > Eelco
> > > > > >
> > > > >
> > > >
> > >
> >
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Bruno Borges <br...@gmail.com>.
To follow with onAttach/onDetach (I don't remember if these has -ed)
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/11/07, Igor Vaynberg <ig...@gmail.com> wrote:
>
> so why is it onadded() here and bind() in ibehavior?
>
> -igor
>
>
> On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > I guess sitting back is not my strongest point :)
> >
> > I just committed a variant of Al's idea:
> >
> > /**
> > * Optional interface for validators ({@link IValidator} and
> > * {@link IFormValidator}) that can react to validators being added to a
> > * component.
> > * <p>
> > * Implementation note: currently we keep this case simple stupid
> > non-generic.
> > * In future versions we may revisit this and support removal events
> (WHEN
> > * removal of validators is ever allowed, which justifies it's own
> > discussion).
> > * Also, we may look at whether this is a common event to support for
> > behaviors
> > * as well. This raises additional questions that need to be answered,
> > hence
> > * we'll start by supporting just the use case when validators are added
> to
> > * forms or form components.
> > * </p>
> > */
> > public interface IValidatorAddListener extends IClusterable
> > {
> > /**
> > * Called right after a validator was added to a {@link Form} or
> > * {@link FormComponent}. A common use case for implementing
> this
> > interface
> > * is for validators to add behaviors to implement client side
> > validation
> > * capabilities, e.g. through JavaScript, Ajax or just by adding
> a
> > simple
> > * attribute modifier that sets a maxlength attribute.
> > *
> > * @param component
> > * component to which the validator was just added.
> > */
> > void onAdded(Component component);
> > }
> >
> > for which you can have an implementation like:
> >
> > private static class MaxLengthValidator extends
> > StringValidator.MaximumLengthValidator
> > implements
> > IValidatorAddListener
> > {
> > public MaxLengthValidator(int maximum)
> > {
> > super(maximum);
> > }
> >
> > public void onAdded(Component component)
> > {
> > if (component instanceof AbstractTextComponent)
> > {
> > component.add(new
> > SimpleAttributeModifier("maxlength",
> > String.valueOf(getMaximum())));
> > }
> > }
> > }
> >
> >
> > Eelco
> >
> >
> > On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > Well, if you feel strongly about this, maybe it is time to open
> > > another discussion about this specifically or (maybe better as we're
> > > having to digest lots of traffic to start with) a JIRA feature
> > > request.
> > >
> > > Eelco
> > >
> > > On 5/11/07, Bruno Borges <br...@gmail.com> wrote:
> > > > Because Wicket is component based... :) We actually reuse components
> > and
> > > > somewhere we want to disable validators. For example: chained
> > components
> > > > where one component if selected, must disable another component's
> > validator.
> > > >
> > > > --
> > > > Bruno Borges
> > > > Summa Technologies Inc.
> > > > www.summa-tech.com
> > > > (48) 8404-1300
> > > > (11) 3055-2060
> > > >
> > > > On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > > >
> > > > > > How about enabled/disabled validators (and their behaviors) ?
> This
> > way,
> > > > > no
> > > > > > counting down is needed and when validatores are disabled, they
> > > > > propagate
> > > > > > this state to behaviors. Removing validators is strange to me,
> but
> > > > > disabling
> > > > > > them for a while, I think this is more reasonable.
> > > > >
> > > > > Maybe. Again would be more in line with behaviors. But now the
> > million
> > > > > dollar question: for what use case? When would you actually ever
> > need
> > > > > to remove or disable a validator? And *if* you would ever need
> such
> > an
> > > > > exotic case, why does Wicket have to do this for you and why don't
> > we
> > > > > tell people to just make this part of the way they implement their
> > > > > validation method?
> > > > >
> > > > > Eelco
> > > > >
> > > >
> > >
> >
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Igor Vaynberg <ig...@gmail.com>.
so why is it onadded() here and bind() in ibehavior?
-igor
On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> I guess sitting back is not my strongest point :)
>
> I just committed a variant of Al's idea:
>
> /**
> * Optional interface for validators ({@link IValidator} and
> * {@link IFormValidator}) that can react to validators being added to a
> * component.
> * <p>
> * Implementation note: currently we keep this case simple stupid
> non-generic.
> * In future versions we may revisit this and support removal events (WHEN
> * removal of validators is ever allowed, which justifies it's own
> discussion).
> * Also, we may look at whether this is a common event to support for
> behaviors
> * as well. This raises additional questions that need to be answered,
> hence
> * we'll start by supporting just the use case when validators are added to
> * forms or form components.
> * </p>
> */
> public interface IValidatorAddListener extends IClusterable
> {
> /**
> * Called right after a validator was added to a {@link Form} or
> * {@link FormComponent}. A common use case for implementing this
> interface
> * is for validators to add behaviors to implement client side
> validation
> * capabilities, e.g. through JavaScript, Ajax or just by adding a
> simple
> * attribute modifier that sets a maxlength attribute.
> *
> * @param component
> * component to which the validator was just added.
> */
> void onAdded(Component component);
> }
>
> for which you can have an implementation like:
>
> private static class MaxLengthValidator extends
> StringValidator.MaximumLengthValidator
> implements
> IValidatorAddListener
> {
> public MaxLengthValidator(int maximum)
> {
> super(maximum);
> }
>
> public void onAdded(Component component)
> {
> if (component instanceof AbstractTextComponent)
> {
> component.add(new
> SimpleAttributeModifier("maxlength",
> String.valueOf(getMaximum())));
> }
> }
> }
>
>
> Eelco
>
>
> On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > Well, if you feel strongly about this, maybe it is time to open
> > another discussion about this specifically or (maybe better as we're
> > having to digest lots of traffic to start with) a JIRA feature
> > request.
> >
> > Eelco
> >
> > On 5/11/07, Bruno Borges <br...@gmail.com> wrote:
> > > Because Wicket is component based... :) We actually reuse components
> and
> > > somewhere we want to disable validators. For example: chained
> components
> > > where one component if selected, must disable another component's
> validator.
> > >
> > > --
> > > Bruno Borges
> > > Summa Technologies Inc.
> > > www.summa-tech.com
> > > (48) 8404-1300
> > > (11) 3055-2060
> > >
> > > On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > > >
> > > > > How about enabled/disabled validators (and their behaviors) ? This
> way,
> > > > no
> > > > > counting down is needed and when validatores are disabled, they
> > > > propagate
> > > > > this state to behaviors. Removing validators is strange to me, but
> > > > disabling
> > > > > them for a while, I think this is more reasonable.
> > > >
> > > > Maybe. Again would be more in line with behaviors. But now the
> million
> > > > dollar question: for what use case? When would you actually ever
> need
> > > > to remove or disable a validator? And *if* you would ever need such
> an
> > > > exotic case, why does Wicket have to do this for you and why don't
> we
> > > > tell people to just make this part of the way they implement their
> > > > validation method?
> > > >
> > > > Eelco
> > > >
> > >
> >
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Eelco Hillenius <ee...@gmail.com>.
I guess sitting back is not my strongest point :)
I just committed a variant of Al's idea:
/**
* Optional interface for validators ({@link IValidator} and
* {@link IFormValidator}) that can react to validators being added to a
* component.
* <p>
* Implementation note: currently we keep this case simple stupid non-generic.
* In future versions we may revisit this and support removal events (WHEN
* removal of validators is ever allowed, which justifies it's own discussion).
* Also, we may look at whether this is a common event to support for behaviors
* as well. This raises additional questions that need to be answered, hence
* we'll start by supporting just the use case when validators are added to
* forms or form components.
* </p>
*/
public interface IValidatorAddListener extends IClusterable
{
/**
* Called right after a validator was added to a {@link Form} or
* {@link FormComponent}. A common use case for implementing this interface
* is for validators to add behaviors to implement client side validation
* capabilities, e.g. through JavaScript, Ajax or just by adding a simple
* attribute modifier that sets a maxlength attribute.
*
* @param component
* component to which the validator was just added.
*/
void onAdded(Component component);
}
for which you can have an implementation like:
private static class MaxLengthValidator extends
StringValidator.MaximumLengthValidator
implements
IValidatorAddListener
{
public MaxLengthValidator(int maximum)
{
super(maximum);
}
public void onAdded(Component component)
{
if (component instanceof AbstractTextComponent)
{
component.add(new SimpleAttributeModifier("maxlength",
String.valueOf(getMaximum())));
}
}
}
Eelco
On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> Well, if you feel strongly about this, maybe it is time to open
> another discussion about this specifically or (maybe better as we're
> having to digest lots of traffic to start with) a JIRA feature
> request.
>
> Eelco
>
> On 5/11/07, Bruno Borges <br...@gmail.com> wrote:
> > Because Wicket is component based... :) We actually reuse components and
> > somewhere we want to disable validators. For example: chained components
> > where one component if selected, must disable another component's validator.
> >
> > --
> > Bruno Borges
> > Summa Technologies Inc.
> > www.summa-tech.com
> > (48) 8404-1300
> > (11) 3055-2060
> >
> > On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > >
> > > > How about enabled/disabled validators (and their behaviors) ? This way,
> > > no
> > > > counting down is needed and when validatores are disabled, they
> > > propagate
> > > > this state to behaviors. Removing validators is strange to me, but
> > > disabling
> > > > them for a while, I think this is more reasonable.
> > >
> > > Maybe. Again would be more in line with behaviors. But now the million
> > > dollar question: for what use case? When would you actually ever need
> > > to remove or disable a validator? And *if* you would ever need such an
> > > exotic case, why does Wicket have to do this for you and why don't we
> > > tell people to just make this part of the way they implement their
> > > validation method?
> > >
> > > Eelco
> > >
> >
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Eelco Hillenius <ee...@gmail.com>.
Well, if you feel strongly about this, maybe it is time to open
another discussion about this specifically or (maybe better as we're
having to digest lots of traffic to start with) a JIRA feature
request.
Eelco
On 5/11/07, Bruno Borges <br...@gmail.com> wrote:
> Because Wicket is component based... :) We actually reuse components and
> somewhere we want to disable validators. For example: chained components
> where one component if selected, must disable another component's validator.
>
> --
> Bruno Borges
> Summa Technologies Inc.
> www.summa-tech.com
> (48) 8404-1300
> (11) 3055-2060
>
> On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> >
> > > How about enabled/disabled validators (and their behaviors) ? This way,
> > no
> > > counting down is needed and when validatores are disabled, they
> > propagate
> > > this state to behaviors. Removing validators is strange to me, but
> > disabling
> > > them for a while, I think this is more reasonable.
> >
> > Maybe. Again would be more in line with behaviors. But now the million
> > dollar question: for what use case? When would you actually ever need
> > to remove or disable a validator? And *if* you would ever need such an
> > exotic case, why does Wicket have to do this for you and why don't we
> > tell people to just make this part of the way they implement their
> > validation method?
> >
> > Eelco
> >
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Bruno Borges <br...@gmail.com>.
Because Wicket is component based... :) We actually reuse components and
somewhere we want to disable validators. For example: chained components
where one component if selected, must disable another component's validator.
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> > How about enabled/disabled validators (and their behaviors) ? This way,
> no
> > counting down is needed and when validatores are disabled, they
> propagate
> > this state to behaviors. Removing validators is strange to me, but
> disabling
> > them for a while, I think this is more reasonable.
>
> Maybe. Again would be more in line with behaviors. But now the million
> dollar question: for what use case? When would you actually ever need
> to remove or disable a validator? And *if* you would ever need such an
> exotic case, why does Wicket have to do this for you and why don't we
> tell people to just make this part of the way they implement their
> validation method?
>
> Eelco
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Eelco Hillenius <ee...@gmail.com>.
> How about enabled/disabled validators (and their behaviors) ? This way, no
> counting down is needed and when validatores are disabled, they propagate
> this state to behaviors. Removing validators is strange to me, but disabling
> them for a while, I think this is more reasonable.
Maybe. Again would be more in line with behaviors. But now the million
dollar question: for what use case? When would you actually ever need
to remove or disable a validator? And *if* you would ever need such an
exotic case, why does Wicket have to do this for you and why don't we
tell people to just make this part of the way they implement their
validation method?
Eelco
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Bruno Borges <br...@gmail.com>.
How about enabled/disabled validators (and their behaviors) ? This way, no
counting down is needed and when validatores are disabled, they propagate
this state to behaviors. Removing validators is strange to me, but disabling
them for a while, I think this is more reasonable.
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 5/11/07, Alastair Maw <me...@almaw.com> wrote:
> > Eelco Hillenius wrote:
> > > Cheers. I'd also like to pull in what you proposed in another thread,
> > > which is to introduce a more generic hook. E.g.
> > >
> > > public interface IValidationBindListener {
> > >
> > > void onAdded(Component component);
> > >
> > > void onRemoved(Component component);
> > > }
> > >
> > > It would still need to be a separate interface to avoid tight coupling
> > > between validators and components (as we like validators to be useful
> > > outside of Wicket as well at some point).
> >
> > Yeah. I like that.
> >
> > I'd call it onAdd() and onRemove(), to keep things consistent (we use
> > onAttach, not onAttached(), etc.). But this is what gets my vote.
> >
> > The only thing we'd have to think about would be removing behaviours
> > when you remove the validator. We can let the validator worry about this
> > with the onRemove() hook, obviously.
> >
> > The only slight issue with that is singleton behaviours that are used in
> > multiple validators. If you add two validators which both add the same
> > behaviour, then when you remove one of them, this behaviour will be
> > removed. Maybe we need reference counting on that, so if the same
> > instance of a behaviour is added twice, it still all works properly when
> > you remove it once. ;-)
>
>
> Yeah. Same thing goes for the same (singleton) behaviors added as
> normal behaviors and later on as validators.
>
> Note that at this stage we don't even support removing validators.
> Maybe we shouldn't to start with, as honestly, while it would make the
> API more complete, I can't realy think of good use cases.
>
> Eelco
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 5/11/07, Alastair Maw <me...@almaw.com> wrote:
> Eelco Hillenius wrote:
> > Cheers. I'd also like to pull in what you proposed in another thread,
> > which is to introduce a more generic hook. E.g.
> >
> > public interface IValidationBindListener {
> >
> > void onAdded(Component component);
> >
> > void onRemoved(Component component);
> > }
> >
> > It would still need to be a separate interface to avoid tight coupling
> > between validators and components (as we like validators to be useful
> > outside of Wicket as well at some point).
>
> Yeah. I like that.
>
> I'd call it onAdd() and onRemove(), to keep things consistent (we use
> onAttach, not onAttached(), etc.). But this is what gets my vote.
>
> The only thing we'd have to think about would be removing behaviours
> when you remove the validator. We can let the validator worry about this
> with the onRemove() hook, obviously.
>
> The only slight issue with that is singleton behaviours that are used in
> multiple validators. If you add two validators which both add the same
> behaviour, then when you remove one of them, this behaviour will be
> removed. Maybe we need reference counting on that, so if the same
> instance of a behaviour is added twice, it still all works properly when
> you remove it once. ;-)
Yeah. Same thing goes for the same (singleton) behaviors added as
normal behaviors and later on as validators.
Note that at this stage we don't even support removing validators.
Maybe we shouldn't to start with, as honestly, while it would make the
API more complete, I can't realy think of good use cases.
Eelco
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Alastair Maw <me...@almaw.com>.
Eelco Hillenius wrote:
> Cheers. I'd also like to pull in what you proposed in another thread,
> which is to introduce a more generic hook. E.g.
>
> public interface IValidationBindListener {
>
> void onAdded(Component component);
>
> void onRemoved(Component component);
> }
>
> It would still need to be a separate interface to avoid tight coupling
> between validators and components (as we like validators to be useful
> outside of Wicket as well at some point).
Yeah. I like that.
I'd call it onAdd() and onRemove(), to keep things consistent (we use
onAttach, not onAttached(), etc.). But this is what gets my vote.
The only thing we'd have to think about would be removing behaviours
when you remove the validator. We can let the validator worry about this
with the onRemove() hook, obviously.
The only slight issue with that is singleton behaviours that are used in
multiple validators. If you add two validators which both add the same
behaviour, then when you remove one of them, this behaviour will be
removed. Maybe we need reference counting on that, so if the same
instance of a behaviour is added twice, it still all works properly when
you remove it once. ;-)
Al
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Eelco Hillenius <ee...@gmail.com>.
> > 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.
>
> I wouldn't call it IBehaviorProvider if it's tied into validators. ;-)
>
> Perhaps call it IBehaviorProvidingValidator and make it extend
> IValidator, so it's more obvious what's going on and what the interface
> is for.
>
> That said, I think I prefer this approach to IComponentFacet for the
> following reasons:
>
> - When a user goes CTRL+SPACE in Eclipse on their component, having an
> add(IComponentFacet) method will be much more confusing and less
> discoverable than add(IBehavior) and add(IValidator) methods.
>
> As a newbie I'd be thinking, "what the hell is a facet?" whereas at
> least "validator" is pretty self-explanatory.
>
> - Conceptually, users are adding a validator. The fact that it adds a
> behavior to help prevent invalid input or add feedback or whatever is
> secondary to its main purpose, which is validation. It therefore
> makes more sense to me that it's an IValidator first and foremost.
> Putting IBehavior on a level footing with that doesn't make much
> sense to me if I'm wearing my user hat.
>
> - It's nice and simple - I don't have to think hard about whether it
> might suck or not. ;-)
Cheers. I'd also like to pull in what you proposed in another thread,
which is to introduce a more generic hook. E.g.
public interface IValidationBindListener {
void onAdded(Component component);
void onRemoved(Component component);
}
It would still need to be a separate interface to avoid tight coupling
between validators and components (as we like validators to be useful
outside of Wicket as well at some point).
WDYT?
Eelco
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Al Maw <wi...@almaw.com>.
Eelco Hillenius wrote:
> 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.
I wouldn't call it IBehaviorProvider if it's tied into validators. ;-)
Perhaps call it IBehaviorProvidingValidator and make it extend
IValidator, so it's more obvious what's going on and what the interface
is for.
That said, I think I prefer this approach to IComponentFacet for the
following reasons:
- When a user goes CTRL+SPACE in Eclipse on their component, having an
add(IComponentFacet) method will be much more confusing and less
discoverable than add(IBehavior) and add(IValidator) methods.
As a newbie I'd be thinking, "what the hell is a facet?" whereas at
least "validator" is pretty self-explanatory.
- Conceptually, users are adding a validator. The fact that it adds a
behavior to help prevent invalid input or add feedback or whatever is
secondary to its main purpose, which is validation. It therefore
makes more sense to me that it's an IValidator first and foremost.
Putting IBehavior on a level footing with that doesn't make much
sense to me if I'm wearing my user hat.
- It's nice and simple - I don't have to think hard about whether it
might suck or not. ;-)
Regards,
Al
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Eelco Hillenius <ee...@gmail.com>.
> The current solution is simple, but I thought there were objections
> because the Validator API is fairly independent of the internal
> wicket?
That was not the immediate concern, as classes implementing both
interface would suffer the same problem. However, it is a point that
still needs some thinking.
So, I think we're close to a workable solution right now. But maybe
not the perfect yet if you take this coupling into account. How would
a completely decoupled version work though?
Eelco
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Bruno Borges <br...@gmail.com>.
I agree...
--
Bruno Borges
Summa Technologies Inc.
www.summa-tech.com
(48) 8404-1300
(11) 3055-2060
On 5/14/07, Eelco Hillenius <ee...@gmail.com> wrote:
>
> On 5/14/07, Ryan Holmes <ry...@hyperstep.com> wrote:
> > fwiw, I think your initial opinion was correct (i.e. validator HAS-A
> > behavior). Besides the reasons you and others already mentioned,
> > couldn't a validator contribute multiple behaviors?
>
> Yep. They can do that now. I've let it rest a bit and still like the
> current solution best, at least considering the code base we have now.
> Unless someone has big objections, I think we're good and can
> concentrate on getting to a release, getting bugs out, etc.
>
> Eelco
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Eelco Hillenius <ee...@gmail.com>.
On 5/14/07, Ryan Holmes <ry...@hyperstep.com> wrote:
> fwiw, I think your initial opinion was correct (i.e. validator HAS-A
> behavior). Besides the reasons you and others already mentioned,
> couldn't a validator contribute multiple behaviors?
Yep. They can do that now. I've let it rest a bit and still like the
current solution best, at least considering the code base we have now.
Unless someone has big objections, I think we're good and can
concentrate on getting to a release, getting bugs out, etc.
Eelco
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Ryan Holmes <ry...@hyperstep.com>.
fwiw, I think your initial opinion was correct (i.e. validator HAS-A
behavior). Besides the reasons you and others already mentioned,
couldn't a validator contribute multiple behaviors?
-Ryan Holmes
On May 11, 2007, at 7:11 AM, Ryan Sonnek wrote:
> The more I think about this, the more I think that a Validator IS-A
> Behavior. Here's why:
>
> * wicket has a very robust behavior infrastructure. The validation
> framework is (intentionally) very minimalist
> * there are a *million* other java libraries that do validation. If
> wicket wants to promote it's own validation library, it needs to be
> broken out as a separate project altogether.
>
> I think it would be best for IValidator to extend from IBehavior.
> That way, any validator can *choose* to perform like a behavior as
> well. This removes the need for separate add(Behavior) and
> add(Validator) methods. The FormComponent can loop through the
> behaviors and do an instanceof check to see if the Behavior is a
> Validator.
>
> Again, I don't see this as bloating the Validator framework. Since
> there are so many validation frameworks out there, I use wicket for my
> web project, not for end-to-end validation.
>
> On 5/11/07, Ryan Sonnek <ry...@gmail.com> wrote:
>> On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
>> > 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).
>> Long term, I think this is the "correct" solution as well. I do
>> agree
>> with your points though that this leads to a more "sweeping" change
>> that affects a lot of the core framework.
>>
>> > 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.
>> Yuk. If they "really" share a common interface, their should not be
>> two separate "add" APIs. overloading the add method for two very
>> different purposes is a very bad idea IMO. I think this should be
>> changed regardless of this new feature.
>>
>> > 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).
>> I agree with Al that seeing an IDE autocomplete a "Facet" instead of
>> "Behavior" or "Validator" is a really big deal. I don't think it's
>> worth it right now.
>>
>> > 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.
>> KISS. Keep It Simple (Stupid) :)
>> The current solution is simple, but I thought there were objections
>> because the Validator API is fairly independent of the internal
>> wicket? I know you have to use this new optional interface, but it
>> makes perfect sense for some of the core wicket validators to start
>> using this feature ASAP. The max-length validator is a perfect
>> example where this feature is needed.
>> Start small, and don't try to support every usecase. IMO, getting
>> the
>> ball rolling with the max-length validation is a great start.
>>
>> Ryan
>>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Ryan Sonnek <ry...@gmail.com>.
The more I think about this, the more I think that a Validator IS-A
Behavior. Here's why:
* wicket has a very robust behavior infrastructure. The validation
framework is (intentionally) very minimalist
* there are a *million* other java libraries that do validation. If
wicket wants to promote it's own validation library, it needs to be
broken out as a separate project altogether.
I think it would be best for IValidator to extend from IBehavior.
That way, any validator can *choose* to perform like a behavior as
well. This removes the need for separate add(Behavior) and
add(Validator) methods. The FormComponent can loop through the
behaviors and do an instanceof check to see if the Behavior is a
Validator.
Again, I don't see this as bloating the Validator framework. Since
there are so many validation frameworks out there, I use wicket for my
web project, not for end-to-end validation.
On 5/11/07, Ryan Sonnek <ry...@gmail.com> wrote:
> On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> > 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).
> Long term, I think this is the "correct" solution as well. I do agree
> with your points though that this leads to a more "sweeping" change
> that affects a lot of the core framework.
>
> > 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.
> Yuk. If they "really" share a common interface, their should not be
> two separate "add" APIs. overloading the add method for two very
> different purposes is a very bad idea IMO. I think this should be
> changed regardless of this new feature.
>
> > 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).
> I agree with Al that seeing an IDE autocomplete a "Facet" instead of
> "Behavior" or "Validator" is a really big deal. I don't think it's
> worth it right now.
>
> > 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.
> KISS. Keep It Simple (Stupid) :)
> The current solution is simple, but I thought there were objections
> because the Validator API is fairly independent of the internal
> wicket? I know you have to use this new optional interface, but it
> makes perfect sense for some of the core wicket validators to start
> using this feature ASAP. The max-length validator is a perfect
> example where this feature is needed.
> Start small, and don't try to support every usecase. IMO, getting the
> ball rolling with the max-length validation is a great start.
>
> Ryan
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Ryan Sonnek <ry...@gmail.com>.
On 5/11/07, Eelco Hillenius <ee...@gmail.com> wrote:
> 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).
Long term, I think this is the "correct" solution as well. I do agree
with your points though that this leads to a more "sweeping" change
that affects a lot of the core framework.
> 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.
Yuk. If they "really" share a common interface, their should not be
two separate "add" APIs. overloading the add method for two very
different purposes is a very bad idea IMO. I think this should be
changed regardless of this new feature.
> 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).
I agree with Al that seeing an IDE autocomplete a "Facet" instead of
"Behavior" or "Validator" is a really big deal. I don't think it's
worth it right now.
> 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.
KISS. Keep It Simple (Stupid) :)
The current solution is simple, but I thought there were objections
because the Validator API is fairly independent of the internal
wicket? I know you have to use this new optional interface, but it
makes perfect sense for some of the core wicket validators to start
using this feature ASAP. The max-length validator is a perfect
example where this feature is needed.
Start small, and don't try to support every usecase. IMO, getting the
ball rolling with the max-length validation is a great start.
Ryan
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Eelco Hillenius <ee...@gmail.com>.
Well, I slept about it for a night, and talked a bit about this with
Al (who basically came up with the new interface) and my conclusion
really is that validators and behaviors shouldn't be mixed at this
stage. Before we allow that, I believe we really need to have a more
solid anwer to what the common thing between the two is, and how to
support this properly. What we have now is imho a relatively harmless
addition, whereas allowing for mixins or whatever we'd call it would
be a conceptual shift which I think we're not ready for.
My 2c,
Eelco
On 5/11/07, Jonathan Locke <jo...@gmail.com> wrote:
>
>
> hey, you didn't mention my ambiguity resolution hack
> (IValidatorWithBehavior). or did it not work out? this seemed like the
> best thing to me if it works.
>
>
> 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#a10437839
> Sent from the Wicket - Dev mailing list archive at Nabble.com.
>
>
Re: poll: validators and behaviors combined... contribute or IS-A?
Posted by Jonathan Locke <jo...@gmail.com>.
hey, you didn't mention my ambiguity resolution hack
(IValidatorWithBehavior). or did it not work out? this seemed like the
best thing to me if it works.
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#a10437839
Sent from the Wicket - Dev mailing list archive at Nabble.com.