Validation Options for ADF BC Applications
There are various options for handling validation in ADF BC applications:
•Business services. You should build in as much validation as you can when creating the business services in order to protect the integrity of the data in the database and to prevent malicious attacks. There are a multitude of opportunities to add validation at the business services level:
-Oracle ADF Business Components provides a number of predefined validation rule classes that enable you to add business logic without writing a single line of code, or you can also add programmatic validation.
-You can implement validation in the database; however, such validation cannot be exposed in the UI. For example, you cannot use database validation to expose a list of valid values in the UI.
•User interface. The ADF Faces input components that you use to build the pages of your application also have built-in validation capabilities. You use these prebuilt ADF Faces validators to ensure that when a user edits or enters data in a field and submits the form, the data is validated against the rules and conditions you have specified. However, UI validation should always have equivalent validation at the business services layer, so that the same validation is applied when the model is exposed in other ways.
Triggering Validation Execution
Each entity row tracks whether or not its data is valid. When a user modifies a persistent attribute of an existing entity row or creates a new entity row, the entity is marked as invalid, and any validation that you have implemented is evaluated again before the entity is again considered valid. In validation rules, you can specify when this validation is executed as follows:
•Validation Level: In an entity validation rule, you can specify whether validation should be performed at the entity-level (the default) or at the transaction level. If you specify that it should be performed at the transaction level, it will be carried out after all entity-level validation. For this reason you should use this option where you want to ensure that a specific piece of validation is performed at the end of the process.
•Conditional Execution: You can enter a Boolean condition using a Groovy expression to define conditional validation execution. When the condition evaluates to true, the rule is executed. You have the option to test your expression to see if it is valid.
•Triggering Attributes: By default a validator fires on an attribute whenever the entity as a whole is dirty. However, in an entity validation rule, you can choose to trigger validation only when certain attributes change (when one of the triggering attributes is dirty).
Validation always occurs before changes are posted to the database. If you must code validation that depends on seeing posted changes, override the beforeCommit() method in the object’s Java file.
Handling Validation Errors
When a validation rule throws exceptions, the exceptions are bundled and returned to the client, and any database changes pertaining to the transaction are rolled back.
The Failure Handling tab in the Validation page of the Validation Rule page of the entity object editor (or the attribute editor) is where you specify the error message that you want to display to the end user when the validation fails.
You use the Validation Failure Severity option buttons to specify whether the message is an Error message (default) or Informational Warning.
You can enter Groovy expressions to populate variables in error message text to make the message more meaningful. And you can store messages in a resource bundle or property file to make them translatable.
Specifying the Severity of an Error Message
If you define the message as an Error message, the end user is not able to navigate out of the current field or record and must revisit the field where the data has failed the validation test. If the message is classified as a Warning, the user can continue after the message has been acknowledged.
Using Groovy Variables in Error Messages
Using Groovy variables in error messages enables you to display dynamic labels and values in your messages. This also makes your messages more reusable when adding to a resource, as described in the next slide.
When you create the message, use any variable name, surrounded by curly braces. JDeveloper automatically adds the variable as a message token in the lower part of the Failure Handling page.
You must supply the values for the message tokens. You can use expressions such as source.hints.OrderDate.label to reference the value of the user-friendly display label of the OrderDate attribute of the source entity object being evaluated. To reference the value, simply use the name of the attribute.
At run time, the error message is displayed with the specified labels and values.
Storing Error Messages as Translatable Strings
Typically you store error messages in a resource bundle or other property file to facilitate translation and reuse of messages. A resource bundle contains key-value pairs for any messages and data strings in your application that you want to translate or reuse.
To use an existing message or create a new stored message, perform the following steps:
1. Click the Select Text Resource button to go to the Select Text Resource dialog box.
2. In the Select Text Resource dialog box:
-To use an existing message, select it and click Select
-To create a new message, enter the message in the Value field. This automatically populates the Key field, but you can change the key to a more meaningful name if desired. You also enter a description, which can assist the translator in knowing how the message is to be used.
-Click Save and Select to store and use the message
Defining Validation in the Business Services
When you incorporate validation into the ADF BC business model, the most logical place to implement such validation is in the entity objects. Encapsulating business logic in these shared reusable components provides the following benefits:
•Ensures that your business information is validated consistently in every page where end users are allowed to make changes
•Simplifies maintenance by centralizing validation
Using Prebuilt Declarative Validation Rules
The easiest way to create and manage validation rules is through the declarative validation framework. Oracle ADF is shipped with a number of built-in declarative validation rules that will satisfy many of your business needs. You implement these rules through the entity object editor and they are stored in the entity object’s XML file.
You can implement these rules either on the entity object itself, or on its attributes. The next few slides show how to use the built-in declarative validation rules.
Defining Declarative Validation
To include declarative validation on an entity object, perform the following steps:
1. Double-click the entity object in the Application Navigator to invoke the editor.
2. Invoke the Validation Rule editor:
-For entity validation, in the Entity Validation Rule section of the General tab, click Add Validation Rule.
-For attribute-level validation, select the Attributes page and double-click the attribute for which you would like to define a validation rule. In the Edit Attribute dialog box, click Validation in the list on the left of the page. In the Validation pane (with the attribute selected) click New. You can also define attribute.
3. In the Add Validation Rule dialog box, select the type of validation required from the Rule Type list and add details of the rule.
4. Define validation execution rules and failure handling procedures by clicking the relevant tabs and entering the preferences.
5. Click OK. The validation rule is displayed in the list of validation rules for the entity or attribute that owns it.
