Validate Entity or Validate Entity Attribute when using af:table or af:treetable ? ADF BC 11g

Hi,

With this post we are going to investigate which validation is better to use for a specific circumstance. The Entity Validation or the Entity Attribute Validation for the specific case of af:table UI component. Here is our case:

We have rows that have  two input fields that they depend on each other.
For instance, in this example we are going to use the HR schema of Oracle XE,  we are going to have a logic that says that we cannot have an employee with firstName or PhoneNbr. But we can have an employee without firstName and phone Nbr. In other words, we have to set values to both fields or to none of them.

Download Sample Application.

NOTE: This is an example test case and this example might not actually fit any business logic. It is purely illustrative and the scope of this post is to investigate a best practice on the validation approach of two depended fields.

So, what we have now is a business rule. This rule says that we can have an employee with no firstName and no phoneNbr, but, if we must set values, we have to set to both of them.

OK, for this rule we are going to develop both cases for our investigation.

One with Entity Attribute Validations. Method A


One with Entity Validation. Method B

For the simplicity of this example, we will create two separate entities of the employees table and two separate views.

Method A:


Since it is not just a mandatory property and has some logic, for this example we are going to use a method type of validation.

We accept the default name of the method, as proposed from JDeveloper wizard.

In the failure handling section we set a message that corresponds to our business logic:

We do exactly the same ( with a slight difference in the failure handling message) for the PhoneNbr attribute.

For the phoneNbr we have to check the the checkBox in order to generate the method. This is because there is already one method.

Next, we have to right some code in the methods:
NOTE: in case your java class has no accessors, go to the java section of your entity, press the pencil and select the Create Accessors checkBox

The methods for each attribute:

Method B:
For method B, we will do the same process but only once, with one method. Because we are going to create one EntityValidation method. We are using EntityB. The process is the same, but the starting point is different:

Now, we have only one method so we will simply put both conditions of the other entity class into this method:

All we have to do now, is to create two separate pages, each one will have a view Object (already created by the JDeveloper wizard ). All we have to do after the pages, is to... test...

We create the pages and we drag and drop a view to a page:

we set the FirstName and the PhoneNbr as autoSubmit true.

If you run the application and press the first button, we will be navigated to to method A page where we have the entity attribute validations. There, if go and delete the value of the FirstName in the first row, press tab, we will get an error message:

The above is correct. It is exactly what we wanted. Lets go and delete the PhoneNbr of the same row,
Normally, we should not get any error message right? At least, this is the visual logical thought..
However, we still get the error...

This is very logical and expected behavior. Since validations are failed, no values are set in the attributes, thus our method in the second attribute handles the FirstName with it's "old" value which is not old because it has never changed.


Now, if we check the same in the second page, we will not receive the same behavior. We will have the accepted one. The difference here is that the Entity Validation is triggered when the whole entity is submitted. This happened when we change a row by clicking to another record in the table or by pressing a button.




So this investigation and example clearly indicates that when it comes to depended attributes and their validations, the correct declarative way is to use an Entity Validation and not an Entity Attribute Validation

Reference:
http://download.oracle.com/docs/cd/E24382_01/web.1112/e16182/bcvalidation.htm#ADFFD407

Download Sample Application.

Regards.

Entity Attribute Validation Rule (Business Rule) based on Master View Object Attribute Example ADF 11g

Hi,
Here is an example case of entity attribute validation rule.

Download Sample Application.

This example is using HR Schema of Oracle XE.
The following case uses Employees and Departments Entities and View Objects.
All Business components are created through JDeveloper 11g wizard.
The validation will check if the ManagerId attribute of the Employees Entity has the same value as the ManagerId of the Department.
We consider that there should not be the same Manager of a Department and an Employee.
Just to clarify that this is an example and maybe the logic does not seem very logical....
The point is to present the solution.
So, what do we have so far?
Two Entities (Employees and Departments) with their association (Master is the Departments entity)
Two View Objects( Employees and Departments) with their corresponding entities and the appropriate view Link.

Now, as we said earlier, we want to prevent the user from setting managerId value, for an Employee, which is the same as the managerId value for the corresponding Department.

In order to implement this case the declarative way, we are going to create an Entity Attribute Validation Rule  or in other words, Entity Attribute Business Rule.

We locate the Employees entity and the ManagerId attribute and press the green plus sign:

A new wizard window  will appear that will guide us to create the validation we want.
For this scenario, we want to compare the Employees Entity managerId with the Departments View Object  managerId. For that reason, we will select the value View Object Attribute  value of the Compare With  choice list. Further more we set the Operator  to  Not Equals.

Location of te ManagerId

Setting the  Not Equals

The final thing to do is to set an appropriate message that will notify the user that this value cannot be accepted.

This Rule Definition will be triggered  when the Employees managerId attribute is the same as the Departments View Object managerId attribute.

In order to test the example, we do not need to  create any jspx.. Since this is a BC validation, all we have to do is run the Application Module:

In the following example: Department has ManagerId of nbr: 200

 We double click on the Employees view and change the managerId to 200 and press tab. The result will be the following: (the message is just for fun.. .not an actuall logic message.. or is it? :) )

And that is it..
Dont you just feel  a little bit more Declarative now?

Download Sample Application.


Regards.