Don't agree here. Any public API should push you in a direction or
otherwise it would just be a set of utility classes. The question
ofcourse is how far it should push you, which means the difference
between ultra-clear (and thus easy) but inflexible on one extreme and
ultra-flexible but hard to learn on the other. Much depends also on the
kind of problems a framework tries to solve. An IoC framework has a very
different focus and should be much more general purpose than a web
framework imo.
IValidator is part of the Wicket package, which is specifically
designed to support form validation (note the
'wicket.markup.html.form.validation' package). Validators can be coupled
to FormComponents and they are meant just for that. Everyone is free to
implement whatever validation mechanisms for whatever layer they like,
but that shouldn't be Wicket's business. If you want to reuse existing
validators from other frameworks, just wrap them.
Making validators more general purpose would make it less clear how/ for
what they should be used. What use would a validator attached to e.g. a
link or a label be? Furthermore, by providing the FormComponent, you get
acces to things like the form component's converter (which is
overrideable until the component level), and it's name so a default
message key can be constructed using it's id or path.
Eelco
Peter Veentjer - Anchor Men wrote:
Another improvement:
the Validator should not be so thightly coupled to the FormComponent (
have found no reason why it should). The Validator should validate a
value and not a FormComponent and should return a collection of
errors. This way the components are better decoupled and the working
of the components not so thightly integrated.
And you can use the Validator without a FormComponent. I don`t think
you should push users of a public framework to some direction. You can
give them guidelines how to use the tools, but they should be free to
give there own interpretation to the system as long as they obay the
general contracts. This makes flexible system where a lot a code reuse
can take place.
------------------------------------------------------------------------
*From:* [EMAIL PROTECTED] on behalf of Eelco
Hillenius
*Sent:* Mon 18-7-2005 21:38
*To:* [email protected]
*Subject:* Re: [Wicket-user] why such a strange design in the
AbstractValidator
But the conversion itself is usually part of the validation (in my case
usually the most important in the web layer) and the string is exactly
what you get from the user. I wouldn't like to make too many assumptions
here. It would be trivial however, to create a validator base class that
does the conversion and then passes this converted value to its
extending classes.
Eelco
Peter Veentjer - Anchor Men wrote:
> The validators are all based on strings. I would rather have a
> validator that accepts arguments of the right type and the string
> value`s shouldn`t be transformer more than once..
>
> so:
> transform to right type
> validate
> assign.
>
> ------------------------------------------------------------------------
> *From:* [EMAIL PROTECTED] on behalf of Eelco
> Hillenius
> *Sent:* Mon 18-7-2005 21:12
> *To:* [email protected]
> *Subject:* Re: [Wicket-user] why such a strange design in the
> AbstractValidator
>
> I agree that's an improvement. It's less elegant that we have all those
> methods carrying the instance of FormComponent now, but it is better to
> have validators thread safe by default.
>
> If we're going to change this, it will mean an API break for a lot of
> clients, so this will be 1.1 only. And while we're at it, let's see if
> we can improve the validation part further. Phil just filed this:
>
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1240458&group_id=119783
<https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1240458&group_id=119783>
>
<https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1240458&group_id=119783
<https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1240458&group_id=119783>>
> with which I also agree.
>
> Do other people have votes/ idea's on this?
>
> Eelco
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
<http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click>
> <http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
<http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click>>
> _______________________________________________
> Wicket-user mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/wicket-user
>
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
<http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click>
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
