Hi,

On Dec 6, 2007 9:50 AM, Felix Meschberger <[EMAIL PROTECTED]> wrote:

> ...Rather I suggest, we define an extensible input validation system,
> which is used mainly by the microjax handling but may also be used other
> consumers of client supplied input data....

Agreed

> ...I have been looking at the Spring 2.5 validation package [1] for some
> inspiration....

There's also commons-validator, I'm not familiar with it though:
http://commons.apache.org/validator/

> ...The question is, how the
> validator is selected for a given request :
>
>    (1) Simply use the resource type
> or (2) Same as servlet/script resolution take resource type, selectors,
> extension and
>        request method into account...

Seems like the resource type should be sufficient, and the validation
script or code can access more info about the request if needed.

> ...The location of
> the script should be different from the normal request rendering
> scripts, e.g. /apps/<resourcetype>/validators/* (of course this collides
> with a normal request rendering script for the selector "validators",
> which may or may not be an issue)....

We could also simply use the script name, e.g. "validation.js" to
indicate its role, that's consistent with what we do now with POST.js,
html.js, etc.

> ...To use the validation framework, we would have a validation service :
>
>     public interface ValidationService {
>         Errors validate(SlingHttpServletRequest request);
>     }
>
> Scripts and servlets requiring validation would call the
> ValidationService.validate method with the request and response objects....

Ok, so the framework does not call this automatically, scripts have to
call it explicitely, sounds good to me.

> ...The ValidationService internally manages the validator selection and
> call. The validate method returns null if the input validates
> successfully. Otherwise an Errors instance is returned which may be
> inspected and from which a response may be generated to send back to the
> client....

Sounds good, and we should use subclasses of Errors like
RequiredParameterMissing, BadNumberFormat, etc.

One idea (that doesn't impact the overall design): if we can use
javascript to define validation scripts, they might be useful on both
the client and server sides.

-Bertrand

Reply via email to