JDev 11g new features - ADF BC Entity Object Validation Rules part 2 of 3

This is the 2nd post in a 3 part series on the new Entity Object (EO) Validation Rule facilities in ADF Business Components (ADF BC) within the JDeveloper 11g Technical Preview edition. The previous post can be found here, and part 3 here.

The JDeveloper 11g Technical Preview (TP) edition introduces extended functionality which can be categorised under the tabs they exist within the Add Validation Rule dialog. This post specifically looks at the Validation Execution tab within the dialog:

The Validation Execution tab is an entirely new tab since the 10.1.3 release and provides the following new functionality:

Validation Level - under the 10.1.3 release validation was always fired at entity level and immediately. This was an issue if the user had yet to complete work in order to satisfy the business rule. Under 11g, if creating the validation rule at the EO level the Validation Option is available, and validation can be set to fire at entity level or when the transaction is committed. This provides the same sort of functionality and advantages as transactional deferred constraints in the Oracle RDBMS.

Conditional Execution - a Groovy expression may be added to the validation rule that when true enforces the validation rule. As mentioned in the previous post Steve Muench has posted on this under his article Groovy Scripting Tips for ADF Business Components.

Triggering Attributes - if the validation rule is defined at the EO level, one or more attributes can be selected, and if any of the selected attributes' values are changed the validation rule will fire. If the validation rule is created at an attribute level rather than EO level, this option does not appear but rather only the single selected attribute is assumed to be defined against the rule.

Available for Real Time Client Execution - this option is only available for validation rules that are defined against an EO attribute, not for validation rules at the EO level. At this stage I'm sketchy on what this feature does, but I'm guessing it indicates to ADF Faces Rich Client components that it is fine to implement and fire this validation within Javascript on the client side. This will have the advantage of saving a round trip to the mid-tier, with the disadvantage of performance loss on the client.

In summary the 10.1.3 release provided little declarative control over when a validation rule should fire. Within the 11g release the developer now has the ability to be very specific under which conditions a validation rule should enforce its business rules, giving a sophisticated declarative approach to business rule programming with little to no coding required.

Part 3 of this post will look at the final tab within the Add Validation Rule dialog, namely Failure Handling.

Disclaimer: this post is written against the JDeveloper 11g Technical Preview (pre-production) edition. Oracle reserves the rights to remove or change this functionality in the final release so ensure to check your facts if you're using a later version when reading this post.