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

Konrad Windszus commented on SLING-4138:
----------------------------------------

I would propose the following interface
{code}
/**
 * A {@code Validator} is responsible for validating a single piece of 
information according to an internal constraint.
 */
public interface Validator<T> {

    /**
     * Validates the {@code data} according to the internal constraints of this 
validator.
     *
     * @param data the data to validate
     * @return validation error message if validation was not successfull, 
{@code null} otherwise. In case an empty string is returned a generic 
validation error message is used.
     * @throws 
org.apache.sling.validation.api.exceptions.SlingValidationException if the 
method is called with {@code null} arguments or
     * some expected arguments are missing from the arguments map
     */
    String validate(T data, Map<String, String> arguments) throws 
SlingValidationException;
}
{code}

The drawback is that the validate method can only be called through reflection 
(to ensure type safety here). Also I would rely on 
http://docs.oracle.com/javase/6/docs/api/java/lang/reflect/ParameterizedType.html#getActualTypeArguments%28%29
 to figure out which type is expected by the {{Validator.validate}} method. Are 
you fine with that approach or do you prefer something more explicit (not only 
relying on Generics as explained in this article: 
http://www.javacodegeeks.com/2013/12/advanced-java-generics-retreiving-generic-type-arguments.html)?

> Allow validator to support arbitrary types
> ------------------------------------------
>
>                 Key: SLING-4138
>                 URL: https://issues.apache.org/jira/browse/SLING-4138
>             Project: Sling
>          Issue Type: Improvement
>          Components: Validation
>            Reporter: Konrad Windszus
>
> Currently the {{Validator.validate}} method only act on String values. 
> Since type conversion is already built into the ValueMap, it would be good to 
> leverage that and to allow Validator to act on arbitrary types there!
> Also the type conversion from ValueMap should be leveraged to do the type 
> check in {{ValidationServiceImpl.validatePropertyValue}} rather than 
> implementing a new thing in {{Type.isValid()}}.



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

Reply via email to