This is a tricky subject. You're talking about stuff that can fall into either "simple input validation" or "business rules". That is, you can have simple static range checks, or dependencies between fields where what's entered into one can be dependent on a previous one directly, or even indirectly (ie., based on a calculation from an earlier value).
If I'm lucky enough that all of the fields on a given form have static bounds that can be checked prior to submitting the form, then I like to put all of the validators into a single method and call it from one point (or every field if there aren't a lot).
If there are multiple tabs or frames, that creates some coupling between the UI and the validators, because now something needs to know how to bring the first erroneous field to the foreground. The last thing users want is an error message that's on a field buried inside a nest of tabsheets and/or frames that they cannot easily find.
Finally, if any of the field values are dynamic based on business rules, which happens more commonly with javascript-based web UIs, it becomes a bit gnarly to sort out what level has primary control over them. There's also the UI coupling that occurs in this case as well, but the dependency situation can often point to a change that needs to be made to an earlier field rather than the one that's invalid.
Therefore, I think these are best handled as separate use cases.
I also have gotten to the point where I like the notion of treating them as predicates, although I've only worked with them as such in the first scenario above.
Personally, I think you just need an interface with a boolean method which returns whether the content is valid or not and a collection class to register the controls to validate.
This requires a bit of work when you want to add new controls, but if you also have a library of basic validators, it shouldn't be too difficult to do.
I am in the design stage of something like this, I am just not yet quite sure what exact route I want to pursue (changing your mind is a lot easier than changing your code).
This is a tricky subject. You're talking about stuff that can fall into either "simple input validation" or "business rules". That is, you can have simple static range checks, or dependencies between fields where what's entered into one can be dependent on a previous one directly, or even indirectly (ie., based on a calculation from an earlier value).
ReplyDeleteIf I'm lucky enough that all of the fields on a given form have static bounds that can be checked prior to submitting the form, then I like to put all of the validators into a single method and call it from one point (or every field if there aren't a lot).
If there are multiple tabs or frames, that creates some coupling between the UI and the validators, because now something needs to know how to bring the first erroneous field to the foreground. The last thing users want is an error message that's on a field buried inside a nest of tabsheets and/or frames that they cannot easily find.
Finally, if any of the field values are dynamic based on business rules, which happens more commonly with javascript-based web UIs, it becomes a bit gnarly to sort out what level has primary control over them. There's also the UI coupling that occurs in this case as well, but the dependency situation can often point to a change that needs to be made to an earlier field rather than the one that's invalid.
Therefore, I think these are best handled as separate use cases.
I also have gotten to the point where I like the notion of treating them as predicates, although I've only worked with them as such in the first scenario above.
Personally, I think you just need an interface with a boolean method which returns whether the content is valid or not and a collection class to register the controls to validate.
ReplyDeleteThis requires a bit of work when you want to add new controls, but if you also have a library of basic validators, it shouldn't be too difficult to do.
I am in the design stage of something like this, I am just not yet quite sure what exact route I want to pursue (changing your mind is a lot easier than changing your code).
/sub
ReplyDelete