[
https://issues.apache.org/jira/browse/SLING-4027?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14219170#comment-14219170
]
Radu Cotescu commented on SLING-4027:
-------------------------------------
[~cziegeler], the {{ValidatorLookupService}} was meant to allow any type of
validator to be retrieved, irrespective of the way it's implemented (OSGi
service or not). Maybe we should have the same provider logic like you propose
for models.
While the {{Validator}} was meant to validate a single value, multi-value
properties can also be validated. The code has changed a bit since I've donated
it to Sling, but this method \[0\] seems to handle multi-value properties.
For c) I'd stick to returning a boolean value but maybe pass the
ValidationResult object so that the Validator can add its own descriptive
failure messages.
f) sounds cool as it will provide more flexibility if you're thinking to query
all providers for retrieving a model.
\[0\] -
https://github.com/apache/sling/blob/trunk/contrib/extensions/validation/core/src/main/java/org/apache/sling/validation/impl/ValidationServiceImpl.java#L353
> 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
> Assignee: Konrad Windszus
> 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)
