Overview of Locale support

[rob-bygrave]

Goals

• validate a bean with a given locale
• return ConstraintViolations with messages and property names for that locale
• HTTP Accept-Language header -> Locale ... would be nice make this easy

Configuration for Validator.Build

• Default Locale used by default when a locale can't be "resolved"
• Set supplied as all the Locales that the validator instance will support. Extra Locales are not supported on the fly.

LocaleResolver

• Knows the default locale and all supported locales
• Given a requested locale (or Accept-Language) determine the Locale to use (fallback to default)

MessageFinder / ResoureBundleLookupThing (name?)

• Given a message and locale get the correct message template. Expected to use ResourceBundle
• Given a property name and path ... return a it8n version of the property name for a given locale

MessageInterpolator

• Given a message template + attributes parse and return the final locale specific message

Note that in the case where only 1 locale is supported, it is possible to lookup & interpolate the messages once when the ValidatorAdapters are created, otherwise that needs to be done at runtime (with caching) based on the passed in request locale.

[SentryMan]

HTTP Accept-Language header -> Locale ... would be nice make this easy

it'd be pretty trivial to modify the HTTP generator to support this sort of thing.

[SentryMan]

my train of thought completely derailed, are we mostly done with this? what's next?

[rob-bygrave]

Yeah, I've got to do a reset / review of where we are at too.

ResourceBundles ...

In terms of ResourceBundles, there are 3 types in a priority order:

• A) User provided resource bundle ... if a message is found in here it is used (top priority)
• B) "Custom Validators" that provide their own resource bundles (second priority)
• C) The built in ResourceBundles that we already have (bottom priority)

Currently we only have the C) built in ResourceBundles and are missing support for A) and B)

Also not sure where it's at with messages that include the value being validated - {validatedValue} but any message that contains this must be interpolated every time.

Optimisation 1:

At some point we have the possible optimisation that when there is only 1 supported Locale then the message can be interpolated once when the adapter is created (apart from messages that contain {validatedValue} which must always be interpolated every time).

Optimisation 2:

At some point, we have the possible optimisation that when there is 2 or more Locale, then the messages can interpolated once and cached [keyed by locale + message key] (apart from messages that contain {validatedValue} which must always be interpolated at runtime).

Those are the next things to look at off the top of my head.

[SentryMan]

for the optimizations, would it not be simpler if we did optimization 2 every time? (instead of writing a whole separate logic for 1 vs 2+ locals)

[SentryMan]

So #50 took care of a lot, what else remains?

[rob-bygrave]

Maybe no more features. I probably need to do a review and look at the tests.

I thought there was some tests that I missed ... around treating things as not-null-by-default (properties with no annotation are deemed not-null and validated as such)

[SentryMan]

(properties with no annotation are deemed not-null and validated as such)

Properties without annotations are ignored. Null values being validated depends on the adapter as sometimes null is valid.

[rbygrave]

I'll close this now