hrm. after looking at it i dont like it :|
ivalidator is a pretty simple interface. why not simply allow a behavior to
implement it
add(ivalidator v) {
if (v instanceof ibehavior) { add((ibehavior)v); }
...
}
so now a behavior can implement ivalidator. the problem that
ibehaviorprovider tries to solve is to allow one to glue any ivalidator with
any ibehavior. well, that can very simply be done with an adapter class that
simply delegates to the right delegate
class ValidatorWithBehavior implements IBehavior,IValidator{
private IBehavior behavior;
private IValidator validator;
public ValidatorWithBehavior(IValidator v, IBehavior b) {
this.behavior=b;this.validator=v;
}
...delegating methods...
}
this way we do not need IBehaviorProvider. we make behaviors and validators
more flexible because a behavior can also be a validator. there is no
removeBehavior/removeValidator problem because they are the same instance
and only exist once.
my two cents
-igor
On 5/9/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> no. dont forget that the idea of IValidator is to be decoupled from
wicket,
> to allow the reuse of validators in service layer. i do that all the
time
> now and it rocks! my service layer and my ui layer are validated by the
same
> code. adding ivalidator.getbehavior() will break all that nice
decoupling.
>
> i always thought that something like this would work
>
> IClientSideValidator extends IValidator { /** rerturn a js func to
validate
> the value */ CharSequence getValidationScript(); }
/**
* Validator that provides a behavior, e.g. for rendering client-side or
ajax
* validation. This interface can be implemented by either
* [EMAIL PROTECTED] IValidator validators} or [EMAIL PROTECTED] IFormValidator
form validators}.
*/
public interface IBehaviorProvider extends IClusterable
{
/**
* Gets behavior for validation.
*
* @param component
* component currently using the validator
* @return The behavior, which can be used for rendering e.g.
*/
IBehavior getValidationBehavior(Component component);
}
same here, instanceof check and ready. Not extra code as how to
interpret it, and all the flexibility that behaviors provide.
Eelco
