[ 
https://issues.apache.org/jira/browse/SLING-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14218026#comment-14218026
 ] 

Konrad Windszus commented on SLING-4027:
----------------------------------------

b) and d) is solved with SLING-4138.
With those changes the validator will never be called with a null value, 
therefore I consider c) as being resolved as well (I already adjusted the 
javadoc of the {{Validator}} with SLING-4138)

> Improvement of the validation API
> ---------------------------------
>
>                 Key: SLING-4027
>                 URL: https://issues.apache.org/jira/browse/SLING-4027
>             Project: Sling
>          Issue Type: Improvement
>          Components: Validation
>            Reporter: Carsten Ziegeler
>             Fix For: Validation 1.0.0
>
>
> Some comments / thoughts about the validation api:
> a) Why is there a validator lookup service? I don't think we need this in the 
> API - it's a simple OSGI service lookup.
> b) A Validator can only validate a single value - what if a property is an 
> array and the validation needs to validate based on all supplied values? Same 
> goes with dependencies between two properties?
> c) The Validator interface returns null on success and a String (message) if 
> validation fails. But it can also throw an exception if e.g. the provided 
> value is null. I think a null value should be treated the same as a wrong 
> value. Throwing the exception if some configuration like the regexp for the 
> regexp validator is missing, is fine. but all errors of validating a value 
> should be treated the same.
> d) NonExistingTypeException I don't think we need this - 
> IllegalArgumentException is fine to throw from the type enumeration
> e) Maybe we can also remove the SlingValidationException - it is only thrown 
> (see c) if a validator does not get its required configuration - which can be 
> seen as an IllegalStateException
> f) It would be nice to have a ValidationModelProvider interface - we will 
> then have the current way of defining models as the default implememtation. 
> But can allow other means of defining the validation model



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Reply via email to