fix voor validationData

[wpdebruin]

ValidationData always was a string, and so was the IValidionError.getValidationData.
There are already 4 Validators which don't return a string (Unique, ValidateIf, ValidateUnless and Unique)
This caused errors in globalReplacements in ValidationResult.cfc. I replaced it with a more generic if statement, so we don't have to change it for every customValidator or new validator.

This PR adds full globalization for all default validation messages and solves the following issues
https://ortussolutions.atlassian.net/browse/BOX-28
#15
#14
#31 (more or less)

This is fully compatible with old cbvalidation versions, just one potential problem if you are using unknown locales in your app. Which can be adressed. See my note further down.

The changes:

• In ModuleConfig.cfc cbi18n section is added. We really need a default locale here and a localeStorage or everything will fail. These can be overridden in the main coldbox config.
• A resourcebundle alias named cbvalidation has been added where we store all language default messages.
• The alias location is includes/i18n/cbvalidation. This can be overridden in configSettings.validation.cbi18nResourcePath. This opens the possibility to override any default message, and add unknown languages. If you copy the includes/i18n/cbvalidation to your own location you can change any message and add any language you want.
• all validators have a new dependency ResourceService which is added during init.
  an all validation error messages have been replaced by resourceService.getResource("default.ValidationType@cbvalidation"), in some cases some values are added to the resources.
• a globalReplacements call is added to addError in ValidationResult. This is necessary so all replacements in locale resources will allways be processed.

I want to add also a smarter way to handle custom messages in Internationalization.
such as {ObjectName}.{Field}.{ConstraintType}}
This can only be added in a DEFAULT resource now, and I want to have them to be available in any resource alias I want. Can easily be solved by adding another setting called resourceAliasName (or something simular) which can default to 'default' which is the current situation, 'cbvalidation' which is were all default messages are, or something new. Makes it very flexible, and keeps your validation messages in one place. Didn't do it yet, want to discuss the rest first.

There's one problem right now: if you add an unknown locale cbvalidation will fail, because the locale is not there. This is because cbi18n ALWAYS needs a valid locale.
I think providing the most used languages shouldn't be a problem, such as en, es, de, fr, nl.
But most locales have country variants such as en_US, en_UK, nl_NL, nl_BE etcetera. If we provide them all it adds up and we still have no default.
By a simple modification in cbi18n this can be solved. Make the locale lookup hierarchical.
So try to find nl_BE. If it is not there try to find nl (so without the country destination) and if still not found try the default locale.
So let's say cbvalidation_nl_BE.properties, followed by cbvalidation_nl.properties, followed by cbvalidatiion.properties. Which is actually how this is meant in java locales, but cbi18n doesn't implement it yet.
We can make this behaviour optional (so no changes to old cbi18n) but is is way more flexible and if we specify lookupParentResource=true (or something simular) our cbvalidation will never fail.
I created a pull for cbi18n as well so this can be fixed as well

[lmajano]

@wpdebruin can you revise this, seems lots have changed

[wpdebruin]

Ok, I will finish cbi18n first. As soon as that’s how we want it, I’ll start again on cbvalidation, and maybe in smaller parts. Wil Van: Luis Majano <[email protected]> Beantwoorden - Aan: coldbox-modules/cbvalidation <[email protected]> Datum: vrijdag 22 mei 2020 om 15:49 Aan: coldbox-modules/cbvalidation <[email protected]> CC: "[email protected]" <[email protected]>, Mention <[email protected]> Onderwerp: Re: [coldbox-modules/cbvalidation] fix voor validationData (#41) Closed #41<#41>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub<#41 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/ADZG646UAM4IHTTS2FPAXUDRSZ7F5ANCNFSM4K4OJYGA>.