Dive into ADF

Andrejus continues his excellent series of example-backed posts on Oracle ADF with a posting today about how to use the ojdeploy command line utility as part of your automated build infrastructure.

[ Via the XML Publisher Blog ]

Husain takes you step by step through integrating Oracle ADF with BI Publisher for reporting.

Our ADF Patterns team has published a new whitepaper that gives a step-by-step tutorial of using the new UI Shell provided in JDeveloper / ADF 11.1.1.2.0

Oracle User Interface Shell

See the ADF Patterns page for all whitepapers:

http://www.oracle.com/technology/products/adf/patterns/index.html

The 11.1.1.2.0 maintenance release of JDeveloper / ADF is now available for download from OTN.

Find/bookmark updated documentation for this release here.

Among many bug fixes and new features, this is the release that includes the support for the UI Shell you can use in your own applications as I demoed during my OpenWorld 2009 conference presentation on ADF best practices.

A user struggles with a problem in his af:treeTable where an af:inputText field bound to a Name attribute intermittently refuses to edit the value in its table cell, behaving instead as a read-only value. It only occurs on the 2nd and subsequent levels of the tree, and typically happens after doing an Expand All... and then clicking around into different rows of the treeTable. The rows/nodes at the root of the tree are always correctly editable.

The problem stems from the fact that his tree was referencing the value of the Name attribute using the expression #{node.Name} like this:

        <af:treeTable value="#{bindings.ProjectCodeTypeVO1.treeModel}"
                      var="node"
                      selectionListener="#{bindings.ProjectCodeTypeVO1.treeModel.makeCurrent}"
                      rowSelection="single" id="tt1" partialTriggers="::ctb1"
                      editingMode="clickToEdit">
          <f:facet name="nodeStamp">
            <af:column id="c1" headerText="ID">
              <af:outputText value="#{node.Id}" id="ot2"/>
            </af:column>
          </f:facet>
          <af:column id="c2" headerText="Name">
            <af:inputText value="#{node.Name}" id="ot3"
                                  autoSubmit="true"/>
          </af:column>
        </af:treeTable>

The node variable represents the current row in the treeModel's data collection, so the #{node.Name} expression represents the value of that row's Name attribute. However, this is an expression that is fine for read-only access of the Name attribute.

To reliably be able to edit the attribute value in the UI, you need to use the following expression instead which causes the ADF model data binding layer to dynamically create attribute bindings to support the edit of each cell:

<af:column id="c2" headerText="Name">
            <af:inputText value="#{node.bindings.Name.inputValue}" id="ot3"
                                  autoSubmit="true"/>
          </af:column>

Once you use the correct EL expression, the editable tree/treeTable will behave as expected.

I've added example# 153 that illustrates how to validate that there exists exactly one composed detail row of a given type, along with a number of other interesting smaller features like:

• Using a rowset aggregation function in groovy to conditionally assign the default value of the detail based on whether there already exists a row of "Primary" type or not.
• Using a custom framework extension class for ViewObjects that any view object can use to declaratively cause any new row to be added at the end of the default rowset
• Using a ClobDomain and custom EmailAddress domain and the genericConverter in JSF to allow successful data entry for these domain types.
• Initializing a bounded taskflow by declaratively invoking a custom application module method exposed on its client interface
• And more...
  

I use Gmail for my personal email and recently enabled a new feature in the Gmail preferences called 'Always Use https'. I hadn't previously connected this change of setting to the fact that for the last few days my Gmail Notifier has not been working (couldn't connect to mailbox).

Just in case this happens to anyone who reads this blog, here is the solution in the GMail Known Issues site. See the Notifier cannot connect to mailbox with 'Always use https' setting section for a registry patch to apply to make it work again.

Andrejus keeps cranking out the examples! His latest posting describes a downloadable sample that utilizes the new capability in 11g called business logic groups (covered in section 4.8 Defining Business Logic Groups of the dev guide).

This feature allows you to define a business logic discriminator attribute whose runtime value can cause a given set of attribute defaults, validation rules, and UI hints to be used. For example, given an employee you might define a business logic group named "CountryGroup" based on the "Country" attribute because there might be different defaults, validation rules, and/or UI hints for employees based on the country they are from. You could create one business logic unit for the "US" value, one business logic unit for the "UK" value and in this way US and UK employees would be treated differently based on this data-driven value. At some future point in time, you could introduce additional business logic units for countries "IT" and "DE", as well.

The business logic units in a business logic group don't have to live in the same package as the entity object that defines the business logic group. In fact, they might not even live in the same project. They provide a slightly more flexible mechanism than the standard discriminator-attribute-based inheritance support we provide because:

• You can define multiple business logic groups per entity (while Java and ADFBC only allow you to inherit from a single parent).
• New business logic units can be introduced at any time, perhaps as part of tailoring an application for a particular country (continuing with my example above).

A few different people have asked me in the past week to help them understand what functionality they would be missing if they were to decide not to define any entity associations and instead just use view links to connect their view objects.

By defining (let's say a 1-to-many) association between two entities Dept and Emp, you enable yourself to:

1. Navigate programmatically (in Java or Groovy) between an instance of Dept and associated Emp instances and vice versa. This can be useful in navigation and business logic
2. Easily add reference information like a Dname description to a view object based on Emp, and to automatically synchronize that reference information correctly when the foreign key (Emp.Deptno) value changes
3. Easily define view links by just pointing to the association (since it already captures the attribute pairs involved in the relationship)
4. Enable LOVs to be configured on the "reference description" field (e.g. "Dept.Dname") and have the related foreign key attribute (Emp.Deptno) be populated when the user chooses a department by name from the LOV.
5. Leverage runtime "pruning" of attributes and joins when you build a VO with SQL Mode of "Declarative" and you happen to be only showing information related to some of the view objects (see example#141)
6. See the relationships between their entity objects in a business components diagram

There are probably more. These were just the first six things that popped into my head... I'll update this posting if I think of others.