imo we need not request input validation. if you want to restrict, use the repository value constraints :-)
regards, toby On 12/6/07, Bertrand Delacretaz <[EMAIL PROTECTED]> wrote: > 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 > -- -----------------------------------------< [EMAIL PROTECTED] >--- Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel T +41 61 226 98 98, F +41 61 226 98 97 -----------------------------------------------< http://www.day.com >---
