ADF 11g: Model driven display properties in Pojo based Data Controls

ADF 11g allows us to specify display hints, validation rules and a lot of other declarative settings for Attributes in Pojo based DataControls. These specifications influence the way display items based on these attributes are displayed and how they behave. Note: most of the default display settings based on model based settings can be overridden in the application. Note that this does not apply to for example the Validation Rules.

In a previous post, I suggested that the ViewObject in ADF BC seems to be taking over the role as DataControl – suggesting that even in a Pojo based scenario (for example with WebService proxies) a ViewObject should be used as the ultimate linking pin to the View (see:The rise of the ViewObject – or: isn’t the ViewObject the real Data Control?). The functionality discussed in this article demonstrates that we can do more for Pojos than I realized when writing that article. However, POJOs are still not ViewObjects…

In this article I will create a DataControl based on a simple POJO that provides an Employee collection. The Employee bean is a simple bean with several different properies. The EmpManager bean returns a collection of predefined Employees.

Using the emps collection from the DataControl, we quickly create a databound JSF page with an editable table for Employees. It is fully functional and the creation of that page is extremely easy and rapid. However, the default display settings are less than optimal (prompt, format, hint text, no validation rules). We will then see how we can set display hints and other declarative settings in the model, on the Employee data control configuration file. After setting these hints, we can run the page again. All our model level changes take immediate effect and the page looks and acts much better because of it. Even better: these improvements will be inherited in any page based on the Employee data control.

Step 1: we start with an HrmManager class that exposes a getEmpManager() method. The EmpManager itself has a getEmployees() method that returns a List of Emp objects.

The first step is to publish the HrmManager as a DataControl:

After Creating the Data Control, we get the following files created – and the following contents in the Data Control Palette:

Step 2: create a data bound page

We can now use the Pojo based Data Control to create a data bound page that displays a table with Employee records. Drag the emps collection to a new page and drop it as ADF Table:

 This Table Edit dialog appears. You may wonder what <default> means for Display Label.

After pressing OK, JDeveloper adds the Table component to the JSF page and creates a PageDefinition file for all data bindings for this page.

The source code for the JSF page contains columns with inputText elements for all properties in the bean or attributes in the data control. What you may wonder about are the EL expressions referring to bindings.emps.hints… .These provide a label (column header), the requiredness of items, the width, the format and tooltip. Then there also is a generic validator set up. Where does all of this come from? More on that later, let’s first run the page.

Step 3: run the page.

The page looks like this:

It is functional, it is not bad but it is also not very refined. Look at the column headers for example.

Now we will set the declarative model level properties that provides the default for display and behavior in the pages.

Step 4: Locate the Emp.xml file that was created when the HrmManager was published as DataControl. Open the file, for example by double clicking. The editor that opens can be used for setting at the default display properties and validators:

 Step 5: change some of the Control Hints for the Sal property/attribute. For example the Label (used for default prompt or column header), the Format Type, a Tooltip Text, thye width and height etc.

Here I also create a validation rule that specifies that the Salary should not be higher than 5000:

And a suitable error message: 

Some generic Attribute properties can be specified on the first page, including requiredness and updateability as well as default value for this attribute in newly created entities.

 After making these changes, run the page again.

We see some substantial changes, all in the Salary column, all caused by the modifications in the declarative, model based properties. Note the Column Header, the Cell Format, the Tooltip…

 And the validation (failure) and error message:

Resources

Download JDeveloper 11g Application: PojoDataControlsUIHints.zip.