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).

Tags
8 comment(s)
Mohsen Benkhellat

I wish is this could be extended to a full fledged BRE (Business Rule Engine) by providing RuleML (or any other equivalent formalism) based rules, their editor and the engine or at least an interface where we can embed any other available engine (like MS BRE, NxBRE, Drools etc).

That could a lot of work (depending on how much is implemented vs how much is interface based) but I believe it will make XAF unbeatable.

Until then, I am happy coding more and more current XAF rules after I made them persistent.

Mohsen

22 May, 2008
Robert Fuchs

> there's a sample I created myself in the past, you can find it attached to this forum post.

It makes no sense to post such old samples.

It was written for a Beta of XAF and is so hopelessly outdated that I gave it up to get it compiled in 8.1.3.

22 May, 2008
Oliver Sturm (DevExpress)

Well well... I didn't strictly have to change a single line of code in that sample. I did import the classes from the module into a new format project and changed the namespaces and that was it. Sorry that the sample didn't work out of the box, but I'm afraid that's how it is with samples -- they age on their own.

I did take the opportunity to change the lines "EmptyUsedPropertyBehaviour = CheckBehaviour.Check" to "SkipNullOrEmptyValues = false" as indicated by the Obsolete warning. I also found that we still haven't fixed that issue that the Rule class doesn't automatically store away the target for later reuse -- I'll look into that again. So thanks for complaining about the sample! :-)

You can download the new version here.

22 May, 2008
John Botibol

Hi Oliver

The articles are great, keep up the good work :-)

This comment really refers to the previous blog re "partial" validity to which I meant to respond, this has reminded me!

How about a validation "action" flag (as a parameter to the attribute) to indicate whether validation failure should stop the process or merely issue a warning. You could have something like:-

<RuleRequiredField("RuleRequiredField for Position.Title", DefaultContexts.Save, "A title must be specified", True)>

This would perform as per now. OR

<RuleRequiredField("RuleRequiredField for Position.Title", DefaultContexts.Save, "A title must be specified", False)>

This would pop a modal warning but allow processing to continue?

23 May, 2008
10 exciting things to know about XAF - eXpress App Framework Team

Pingback from  10 exciting things to know about XAF - eXpress App Framework Team

22 August, 2008
Walter Gumirato

The "Validation module" link at the beginning on the article is pointing to another link.

Regards

25 January, 2012
eXpress App Framework Team

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

1 February, 2012
eXpress App Framework Team

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

1 February, 2012

Please login or register to post comments.