Felix Meschberger wrote:
> Hi all,
>
> There is a general need to validate input sent from the client to the
> server before actually acting upon the input. Of course, we could leave
> this validation to the implementation of the input consumer. But then we
> would prevent the use of the generic microjax handling of input as we
> would have to implement POST (and other) servlets or scripts for each
> case. 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.
>
> I have been looking at the Spring 2.5 validation package [1] for some
> inspiration. Though I think this package is somewhat overkill for our
> case, there are two interfaces, which look interesting:
>
> * Validator - this is the interface to be implemented by input
> validators
> * Errors - this is the interface gathering all validation issues
>
> For Sling, the validator interface will be rather simple :
>
> public interface Validator {
> void validate(??? input, Errors errors);
> }
>
> The validate method checks the input and reports issues to the errors
> object. I am not sure about the type of the input. Probably it is best,
> if it would be the request object. The validator itself does not send
> any response, it just fills the errors object.
>
> The Validator implementation is registered as an OSGi service (hold on,
> scripting will follow) of type 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
>
> A validator may also be a script. The script would of course get
> different input than a normal request rendering script. 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).
>
> 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.
> 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.
>
> WDYT ?
>
Currently Sling has no means of describing forms or input fields etc. (which
is absolutely fine). Therefore the only interface we can provide for
validation
is to validate the whole request - this means, the ValidationService
interface from above makes sense and is needed.
We also might need an Errors object holding all error information.
But then, I think it might get a little bit tricky. First, I don't see a
need for a Validator interface - there is currently no place to hook it in.
Second, I could imagine that it might get difficult to have a generic
mechanism which creates a "good looking" response out of the Errors
object. Therefore I guess we need some application specific error
handling (whatever that means, I have no clean picture yet).
Depending on what people use to create their response (jsps, javascript
etc.), they are free to use whatever validation framework (spring,
commons validation etc.) in there application. All we need to provide is
a hook to call this stuff at the right time (through the
ValidationService interface or some scripting stuff).
So I think all we need to do is to come up with two additional
resolutions during process handling: resolving the validation service
for the current request and in the case of errors resolving an error
handler.
Carsten
--
Carsten Ziegeler
[EMAIL PROTECTED]
