I use Symfony2's ConfigurationInterface to validate the configuration within my bundle. I make use of its normalization methods so that I don't have to be checking for the existence of values when I parse the config myself.
This one method ignoreExtraKeys has thrown me a curve ball. The docs state:
Allows extra config keys to be specified under an array without throwing an exception.
Those config values are simply ignored. This should be used only in special cases where you want to send an entire configuration array through a special tree that processes only part of the array.
which led me to believe that those extra keys would remain in the resulting array. As it happens, they are not. I could define a rule for each key, but it would be impossible. This particular config file defines the structure of a form, the form types and options that should be passed to each type. There are just too many options to account for, it would neglect custom types and Symfony's Form builder already validates the options.
Before I go writing an extra method to merge those keys back into the array, is there any way to force the Configuration validator to leave the keys in place.
Ie. I would like it to validate and normalize what I configured it to, but to also ignore keys it doesn't know about.
It's possible an option will be added to the ignoreExtraKeys method in Symfony version 2.7.
For 2.6 and below the solution is a little cumbersome. First, the variableNode can be used for any data type with no validation. The data within these nodes remains in the output. The original arrayNode must be replaced with the variableNode then for each child which needs validating, a custom closure must be used with validate.
For example, existing code like:
->arrayNode('options')
->ignoreExtraKeys()
->children()
->scalarNode('sub-option')->end()
->end()
->end()
needs to be converted to:
->variableNode('options')
->validate()
->ifTrue(function($v){
return !(is_array($v) && isset($v['sub-option']) && is_scalar($v['sub-option']);
})
->thenInvalid('Wrong config')
->end()
->end()
This could be made easier by restructuring the configuration.
Related
Beeing new to Vue.js and VeeValidate I was wondering in what order validator functions (rules) associated to a field were validated? (as the doc doesn't really mention it)
I was used to Angular docs about validator function and want to know if sync validator are called before async ones.
After looking at VeeValidate 2.0.9 source code about validator.js starting line 649 we can note a _validate method that will (roughly):
Create an Array with the field rules using Object.keys then do a some on it
Use the _test method and store the result (that is directly the result of the validation or a Promise)
Stack async (and sync if a fastExit property is false on this Validator instance) validators (Promise) in an array with a push
Exit if an error occur on a sync validator (with the fastExit property)
reduce the Array containing all of the results to return a final result with errors stacked
So quoting MDN about the Object.keys method:
The Object.keys() method returns an array of a given object's property names, in the same order as we get with a normal loop.
And to quote another stackoverflow answer:
Quoting John Resig:
Currently all major browsers loop over the properties of an object in
the order in which they were defined. Chrome does this as well, except
for a couple cases. [...] This behavior is explicitly left undefined
by the ECMAScript specification. In ECMA-262, section 12.6.4:
The mechanics of enumerating the properties ... is implementation dependent.
However, specification is quite different from implementation. All modern implementations of ECMAScript iterate through object properties in the order in which they were defined. Because of this the Chrome team has deemed this to be a bug and will be fixing it.
Conclusion
The final order will be dependent of the browser implementation of Object.keys, so mostly by the order of definition of the validators but could also be alphabetically!
By default the fastExit property is false but could be overwritten in the validator options. This option will take the first false result from sync validators and return it's errors. If not set the result will be a compilation of all errors after the verification of every validators.
I ran into this issue: our SpringMVC Validator validates a form (the normal case); this works OK.
Also, in a separate use case, it needs to be called remotely from a different location to put an exclamation point icon ("!") in front of some element on a different screen that refers to that form object.
I can validate any object of the class supported by the Validator, but the issue is how to add errors:
1) On the one hand, this Validator should reject errors for the path on its screen when it's used in the normal case:
errors.rejectValue("object.field.path", "errorCode", args, defaultMessage);
2) On the other hand, this will fail when it's called remotely, this path doesn't exist because the form is different. The only thing I can do here is something that doesn't depend on paths,
errors.rejectValue("errorCode");
Ideally the same Validator should respond to both cases... It should tell me there are validation errors on the form. In Case A it's specific, in Case B it's general. Can anyone advise how to approach this?
UPDATE The issue is general Bean Validation vs. GUI Validation. I understand is that SpringMVC's Validators are strongly tied to the GUI. But we also need a generic way to validate data beans, and hopefully reuse that. Or maybe I can create a "mock" BindingResult/JSP?
Since there seem to be no methods for input validation in JavaFX, I was thinking about how to do it in a clean way in my current project.
Here is my idea:
All validation rules are regular expressions (like "min-length", "not-empty", "only-numbers", etc), which are stored in a .properties file
Example: validationrules_only_numbers="[0-9]+"
I use this validations in the .fxml file by defining the <properties> tag for any input that should be validated
Example:
<ChoiceBox><properties rules="%validationrules_only_numbers"/></ChoiceBox>
In an abstract/parent controller I write a method which gets all children of the current AnchorPane and iterates over them (lets say after the user clicks OK to submit the form). All children which have validation rules are them passed to another method, which depending on the Type of the inputfield applies the validation rules to the input.
All controls with validation errors then get highlighted.
What I personally like about this idea:
the validation rules are easily expandable by just adding them to the .properties file
the rules are assigned in the .fxml file
all the controllers (which extend the abstract/parent controller) dont need to perform any validation tasks
What I dont like/am unsure if it works good in reality:
the validation rules are all regular expressions, I don't know if that works well with all the input fields (but I don't mind coding "hacks" to make it work, since I would do it only one time in a parent controller)
I must check the controls with instanceof to apply the rule correctly for this specific control, since not all controls have a getText() method and the input needs to be validated in other ways
don't know if there is a better way to put the rules in the .fxml file then using <properties>
What are your thoughts? Is there anything important I am missing here?
I was googling about this topic for several days and there seems to be no really good solution like those we are familiar with from the web development community.
Before you re-invent the wheel you might want to have a look at the validation framework contained in the ControlsFX package. Maybe you can combine that with your ideas.
Taking some ideeas regarding validation from this book , is it really a good practice and proper SoC to put data validation inside domain objects? There he gives example about validating addresses, checking if it is between an interval of chars long, adding a pattern etc. When thinking about validation isn't better to put the validation right when the user asks something from the application , for example in a command object (cqrs) and stop the user if the command is invalid? Also another problem comes with internationalisation , how would handle the patterns for different alphabets? Also another problem comes with duplicate checks, what if the domain objects checks for each invariant of the property (when it can be of mixed type) but the command actually assumes only one single invariatn to be valid ?
Why I am confused is because Eric Evans forewards this book written by Vernon , but i find some design styles innapropriate . So is it better to validate properties format (string lenght, string format etc, like that address example) in the domain or outside the domain ?
There is user input validation (usually input format) and business rules. The input validation makes sense to be done at the entry point (usually a controller and depending on a framework it can be automatically done), there's no benefit in sending invalid data forward for processing.
However, the domain contains most of the input validation rules so it seems you have to choose between keeping the rules inside the Domain or repeating yourself. But you don't have to, because the input validation can be easily encapsulated into value objects (VO) so they are part of the domain but you can still use them outside the domain to validate the input.
That's why it's best to use VO as much as possible , they usually are domain concepts AND they ensure the value is valid. The entity using them simply must refuse a null value.
I don't how you can validate a command, at most you can check if the user or context can create and send that command, but the command itself is just a semantic DTO with the relevant parameters. It's up to the command handler to decide how valid the command is. Also, I don't think a command should assume anything, it' about what to do not, how to do it.
About i18n, IMO the validator must be aware of the current culture so a possible solution is a service which return the pattern for the current culture. This means the validator (I usually implement it as a static method of the VO) will take something like IKnowValidationPatterns as a dependency.
I have a domain class which gets updated from the UI. It was some constraints to enforce that the users fill in all the required information and all is well.
However, I also have some quartz jobs which update the domain and they do not necessarily need to adhere to all those constraints. I'd like to ignore specific ones so that save() works.
There are a couple of ways I can think of doing this:
Use save(validate: false) but then that will ignore all the constraints (not exactly what I want)
Remove the constraints which only apply to the UI and manually check that the data is valid in the controller
Wrap these constraints into validators which only kick in if the value of a transient property is saveFromUI (set this transient property from the controller before save())
These all seems as hacks. Any other (better) ways?
Almost sounds like you need to consider using a command object.
However, you can always specify which properties to validate in your case of update. So something like this:
myDomainInstance.validate(['prop1', 'prop2'])
...
myDomainInstance.save(validate: false) // since you already have done so manually prior to this.
The documentation has more information about validation.