I would extend "additionalTags" for this purpose.
Yes, I thought about this, but I a) can't see a way for doing this in a backwards compatible manner (i.e. without breaking existing users of this attribute) and b) it makes the use case of only adding elements (without attributes) more complicated:
@SafeHtml( additionalTags = { "foo", "bar"}
vs.
@SafeHtml( additionalTags = { @Tag( name = "foo" ), @Tag( name = "bar" ) }
Therefore I think adding a new attribute is the better option.
Furthermore own WhiteList implementations could be provided.
But how realistic is this? The problem I see is that you can't create a specific WhiteList sub-class based on the existing factory methods such as basic(), relaxed() etc. I think the JSoup API really is centered around obtaining instances via these factory methods and configuring them as required. Note that I'm not strictly against the idea, I'm just wondering how practical it is in the end. I'm also not using JSoup myself; are you working with the sub-class based approach?
Using same "@SafeHtml" on multiple entities with same attributes one would have to either wrap it into a new validator itself or solve it with the class approach.
The BV approach for this would be to create a composed constraint which allows to share the same config between several entities:
@Documented
@Constraint(validatedBy = { })
@Target({ METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER })
@Retention(RUNTIME)
@SafeHtml(
whitelistType = BASIC,
additionalTagsWithAttributes = @Tag( name = "div", attributes = { "class", "style" } )
)
public @interface SafeHtmlWithDivs {
String message() default "{org.hibernate.validator.constraints.SafeHtml.message}";
Class<?>[] groups() default { };
Class<? extends Payload>[] payload() default { };
}
@SafeHtmlWithDivs
private String html;
Like following example: ...
This appraoch does not really work as you can't refer to an instance of an arbitrary class (such as WhiteList) from within an annotation. The only options are to a) refer to a class which is then instantiated in the validator implementation (whitelistClass=...) or b) "describe" the required whitelists (via additionalTags and the like) and instantiate and configure a WhiteList object in the validator according to this description.
|