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

This is the 3rd and final 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. Follow these links for the previous posts part 1 and part 2.

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 Failure Handling tab within the dialog:

The Failure Handling tab is an entirely new tab in the 11g TP release and provides the following functionality:

Validation Failure Severity - errors are now categorised into errors and warnings. An "error" based validation rule if invalidated will display the corresponding error message and will not save the changes until the issue is fixed. Alternatively "warning" based validation rules will fire on exactly the same conditions, but if the validation rule condition is true, while an error message is still displayed, the transaction will not be halted. This provides a nice mechanism to give users informational messages about problems in the data they entered, but not stopping them from saving their work just in case the user knows more than the business rule assumes.

Message Text - this field allows the entering of an error message including positional message expressions (see below). This is similar to the 10.1.3 functionality of entering an error message to display when the validation rule is invalidated. However in the 11g release via the new Select Message button, you may in the associated dialog select an error message out of an existing message bundle file, or even create a new message bundle file. Of particular use this allows you to reuse existing messages defined once in a single message bundle, unlike the 10.1.3 release where error messages where stored in separate MsgBundle class files for each EO.

Error Message Expressions - error messages may include positional fields to be substituted when the error messages is displayed at runtime to make the message more meaningful to the user. The positional fields take the form {n} within the error message where n is a sequential unique number within the error message. The Error Message Expressions option is populated with rows as you enter new substitution variables in your message. The value for the message to be displayed at runtime is defined by a Groovy expression.

Note: the use of positional fields in error messages was supported in 10.1.3, but the dialog did not include this level of sophistication for specifying the fields nor adding Groovy expressions.

In summary within the 10.1.3 release the error messages associated with validation rules was a simple text message. In the 11g release the developer now has the declarative ability to easily parameterise error messages from a single standard message bundle with no coding required.

In summary to the 3 part post, the declarative approach adopted in the EO validators in JDeveloper 10.1.3 and expanded upon in the JDeveloper 11g Technical Preview release, within software development saves much complex coding and uses a tested framework over writing custom validation code that may be error prone (no pun intended). However if necessary the programmer still has the flexibility to drop back to code and write whatever functionality if deemed necessary.

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.