XAF - 3 - Validation and what (else) you can do with it

This is post no. 3 in the mini series "10 exciting things to know about XAF". You can find the announcement of the series here.

The Validation module in XAF is probably one of the most important functional modules we offer, and with its flexibility comes complexity. Documentation about the module is pretty complete, but I'm going to link to the most important topics from this article and try to summarize various considerations about data validation in general.

Validation of data through the module is usually achieved by applying RuleXXX attributes to either persistent classes or their properties in code. There are currently ten different rule types we deliver with XAF, and each of these has a corresponding attribute. Some rules implement pretty simple value restrictions, like the RuleStringComparison or the RuleRange. Others allow for more complex checks across types, like RuleIsReferenced or RuleObjectExists. Finally it is also possible to apply any XPO compatible criteria through RuleCriteria (hint for that last one: if you need help writing those criteria strings, try reading this docs page and this docs page and also this blog article).

Note that the attributes in code aren't the only way of applying rules. It's also possible to use the Validation node in the Application Model to configure them. This makes it possible to leave certain aspects of the rule configuration for the time when the application is deployed to the customer's site.

These validators we deliver out of the box do a pretty good job of covering all the basic scenarios, but when we created the system, we were also expecting people to check more complex scenarios. This is business logic we're talking about, and of course we can't implement it for you. So we made the validation system extensible. When researching for this article, I found that we have a certain lack of documentation and samples for custom validators - there's a sample I created myself in the past, you can find it attached to this forum post. I'll try to get some more material created about this in the future - it's not really hard to do though, since it's basically one class with one overridden method you need to implement (and a second class with boilerplate code to make the rule accessible through an attribute).

Validation in our system always happens according to contexts. This is based on the understanding that validity is not something that can be determined absolutely - in reality what we want to check is fitness for a particular purpose. When I wrote the original user stories for our Validation module, I was going to call it Plausibility Checking instead, in order to reflect that fact. Somehow that name got dropped through lack of use though... anyway, contexts. Every time a rule is applied, it is associated with a context. The context in turn is just represented by a string, a context ID if you will. Technically, there are no contexts in XAF that are built in. There is a standard controller though, which checks two default contexts we deliver, named Save and Delete, and for convenience we also have a DefaultContexts class that makes it easier to apply these contexts correctly.

Now, the important thing to realize is that you can have as many different contexts as you like, and check them whenever you like. The "standard" contexts are automatically checked through a controller class, and you can do the same thing for your contexts if you want. You can also just check them when a certain Action is triggered, for instance, or at any other point. Here's the documentation about custom context checking..

That's almost it already - I'm surprised this article isn't longer :-) But there's one other thing I want to mention: an interesting discussion I posted a while ago about the meaning of "partial" validity (here's a followup to the first post).

Free DevExpress Products - Get Your Copy Today