Not applying logic in ValidationDef when validating child members with Valid attribute
Description
Environment
Attachments
Activity
Fabio Maulo December 9, 2010 at 3:10 AM
Please open another issue ticket for the Improvement of the classValidator internals.
Thanks.
Dan Malcolm December 6, 2010 at 9:26 AM
I made a couple of changes to ClassValidator to help me find my way around, which might help others new to the project. Over to you to decide how useful you think they are
1. Removed the nestedClassValidators parameter from InitValidator. It points to the same collection as the childClassValidators field and it seemed clearer just to access the field.
2. Extracted EstablishChildValidator method to apply DRY to the logic of checking whether child validator exists before initialising it. Also, this allowed me to add a "helpful" comment about how child validators are related to parent within the new Establish method.
Thanks for looking at this.
Fabio Maulo December 5, 2010 at 9:09 AM
Partially applied revision 1450
Fabio Maulo December 5, 2010 at 9:04 AM
I have partially applied the patch changing only the StateFullClassValidatorFactory and all tests are passing (including your new test).
Why those modifications to ClassValidator ?
Dan Malcolm March 10, 2010 at 1:30 AM
Amending description of what the patch does as follows:
The simplest fix is to modify StatefulClassValidatorFactory.GetChildValidator so that it doesn't create a new child ClassValidator if a validator for the child type exists in the collection of root validators. If a validator already exists, this will be used as the child validator, allowing it to use the validator that was created at configuration time.
Details
Details
Assignee
Reporter
Dan MalcolmComponents
Fix versions
Affects versions
Priority
Minor
Hi
I'd like to help out on a problem with validating nested entitites with rules on ValidationDefs (there's currently a TODO in StatefulClassValidatorFactory.GetChildClassValidator: // TODO : Add any existing validators to child of the parent validator).
Let's use the following example:
ClassA has attribute based rules and a property of type ClassB
ClassB has a combination of attribute rules and some rules in a validation def
public class ClassA
{
[NotNull]
public string Name { get;set;}
[Valid]
public ClassB Child {get; set; }
}
After the ValidatorEngine has been configured, we will have a ClassValidator for ClassB in the validators collection of StatefulClassValidatorFactory (along with any others that have ValidationDefs).
When we validate ClassA a new ClassValidator is created on-demand. Then, a new ClassValidator instance for type ClassB is created for the Child property, but this is currently based only on the attribute rules (reason for the TODO I guess).
The simplest fix is to modify StatefulClassValidatorFactory.GetChildValidator so that it doesn't create a new child ClassValidator if a validator for the child type exists in the collection of root validators. When the ClassValidator for ClassB validates the Child property it will then request a root validator from the factory, which will return the validator that was created at configuration time.
Right now, I can't see an issue with us using the same ClassValidator instance to validate a certain type, regardless of the member that references it. With the current initialisation logic, a ClassValidator for a specific type will always have the same rules.
I know that there's been some discussion about the idea of having different ClassValidator instances with varying rules dependent on the context. I think that this would require quite a few structural changes to the validator initialisation logic. Until this has been done it might make sense to apply an interim fix.
Thoughts / suggestions welcome.