Chandu Bhavsar's Oracle ADF Blog

Partial Page (PPR) Navigation

2009-04-16T23:42:00.000-07:00

Continuing with the theme of few past posts of examining PPR related topics:

This post examines a very cool functionality new in 11g called PPR navigation, about which I haven't noticed much mention elsewhere. The fundamentals of working with navigation components in ADF (which derives the functionality from JSF) are explained here. PPR navigation triggers navigation through a PPR request, which means the client does not leave the original page even with a navigation request.

Since the documentation for PPR navigation is precise, what this blog post attempts to do is illustrate the functionality with small sample workspaces for all 3 options for this PPR Navigation option. Each of these workspaces contains an app with 2 pages, each with a command navigation button, which navigate back and forth between the pages. This is an extremely simple usecase application, the point being to illustrate only this configuration option; rather than as part of some elaborate application.

PPR Navigation off : Sample workspace

The behaviour in this case is as with regular JSF navigation, in which the client actually switches from page to page with each navigation request. Note that altering partialSubmit attribute to true or false for command components involved in navigation has no impact on the behaviour with this option.

PPR Navigation on : Sample workspace

This is the cool behaviour. For example, run a JSPX page such as untilted1.jspx from this app, and repeatedly click on the command navigation buttons, such that contents of untitled1.jspx and untitled2.jspx keep getting displayed; all the while the browser title stays on untitled1.jspx. As stated in the documentation, partialSubmit must be set to true for any command components involved in navigation. In the sample workspace, this is true for both command navigation buttons.

What's more, this functionality uses the hash portion of URL, such as examples below. This means it is even possible to bookmark individual pages of the application this way.

#%2Funtitled1.jspx%20%3F_adf.ctrl-state%3D38iv9zp5j_3
#%2Funtitled2.jspx%20%3F_adf.ctrl-state%3D38iv9zp5j_3

Very cool indeed!

PPR Navigation onWithForcePPR : Sample workspace

With this option, if a command component action is navigation, it automatically does navigation using PPR (as if the option was set to "on"). This is true irrespective of the value of partialSubmit attribute set for those components. In fact, in order to drive home the point I explicitly set partialSubmit to false for both buttons in my app; and even then with this option the application behaves with PPR navigation. Pay special attention to the documentation notes for this option for other cases.

Evaluating EL expressions with ADF declarative debugger

2009-04-03T02:38:00.000-07:00

I've been meaning to blog about this for quite a while, and finally found the time for it.

ADF in 11g includes a new, very powerful declarative debugger which has been blogged about elsewhere and documented in the application developer's guide. This is a great developer productivity improvement tool. The guide contains section documenting setting declarative breakpoints and a dedicated subsection explaining evaluation of EL expressions in the declarative debugger.

What I intend to do with this post over and above this good information, is provide supplementary illustrations specifically for evaluating EL expressions. For example, consider a rich tree component such as follows. Depending on the tree node being selected, screenshots are presented evaluating various EL expressions based on the node variable. As the screenshots illustrate, this capability to evaluate EL expressions is very cool, a great developer productivity boost indeed.

    <af:tree value="#{bindings.DivisionsVO1.treeModel}" var="node"
             rowSelection="single" displayRow="selected" id="t1">
      <f:facet name="nodeStamp">
        <af:switcher facetName="#{node.hierType.viewDefName}"
                     defaultFacet="dummy" id="s1">
          <f:facet name="dummy">
            <af:outputText value="Dummy Text" id="ot1"/>
          </f:facet>
          <f:facet name="model.view.DivisionsVO">
            <af:commandLink actionListener="#{bindings.DivisionsExecuteWithParams.execute}"
                            text="#{node.Description}" disabled="false"
                            id="cl1">
              <af:setPropertyListener from="#{node.hierType.viewDefName}"
                                      to="#{sessionScope.viewDefName}"
                                      type="action"/>
            </af:commandLink>
          </f:facet>
          <f:facet name="model.view.ProductGroupsVO">
            <af:commandLink actionListener="#{bindings.ProductGroupsExecuteWithParams.execute}"
                            text="#{node.Description}" disabled="false"
                            id="cl2">
              <af:setPropertyListener from="#{node.hierType.viewDefName}"
                                      to="#{sessionScope.viewDefName}"
                                      type="action"/>
            </af:commandLink>
          </f:facet>
          <f:facet name="model.view.TopLevelSpecsVO">
            <af:commandLink actionListener="#{bindings.SpecsExecuteWithParams.execute}"
                            text="#{node.Description}" disabled="false"
                            id="cl6">
              <af:setPropertyListener from="#{node.Type}"
                                      to="#{sessionScope.viewDefName}"
                                      type="action"/>
            </af:commandLink>
          </f:facet>
          <f:facet name="model.view.SpecsVO">
            <af:commandLink actionListener="#{bindings.SpecsExecuteWithParams.execute}"
                            text="#{node.Description}" disabled="false"
                            id="cl7">
              <af:setPropertyListener from="#{node.Type}"
                                      to="#{sessionScope.viewDefName}"
                                      type="action"/>
            </af:commandLink>
          </f:facet>
        </af:switcher>
      </f:facet>
    </af:tree>

Rationale behind ADF Faces isInitialRender flag deprecation

2009-03-23T16:56:00.000-07:00

To those who might've been visiting my blog over past few months:

I'm back after a long break. I had some health issues which needed to be taken care of in late November and most of December 2008. And since then, I had gotten incredibly busy with day-to-day work that left no time for blogging. So much so, that I didn't even have time to visit my own blog page to find out visitor patterns, check for user comments etc. I notice that the first user comment for this blog had been posted back in December 2008, which I haven't had chance to reply to. Hope to get to it very soon.

Now that that's out of the way, the purpose of this post was to explain one of the points which had been touched upon in an earlier post of mine. In it, I mentioned AdfFacesContext function isInitialRender not functioning correctly, notwithstanding its usage discouraged in the Javadoc.

I finally got to the bottom of why its usage is discouraged, why it doesn't work as per Javadoc description and why it doesn't matter. One sentence summary is:

DO NOT USE THIS FUNCTION!!!

Not only is it deprecated, it doesn't work and shouldn't be expected to work. What is that all about, why is this function there in the first place? I am cutting and pasting the reasoning I received from the authoritative source behind this (as much as possible quoting verbatim, with slight contextual modifications):

ADF doesn't have any available method to know that you are rendering a page or page fragment for the first time. Instead, it is recommended that the user use task flow method-call activities to accomplish any kind of "initial render" setup before forwarding the page for rendering. The complication is that if you have UI components in the page that perform lazy data fetching, the page will actually render using two separate HTTP requests (one for the initial page, and another one for the lazy data fetch). There is no way that ADF Faces currently exposes to detect if you are in the "lazy data fetch" request. So, in general there is no way to know if a page or page fragment is being rendered the first time.

There you have it. Reiterating: Do not use the isInitialRender() function.

Programmatically determining whether a request is a PPR request

2008-11-17T16:16:00.000-08:00

This post examines a very simple programmatic technique for determining whether a specific ADF Faces request is a non-PPR request or coming through a PPR. It is supported through a single call isPartialRequest in class AdfFacesContext, and a small workspace illustrating this functionality is provided.

I was in fact planning to provide a testcase in this sample, illustrating use of related function isInitialRender in class AdfFacesContext as well. That function is supposed to determine whether an ADF Faces request is the first request to render a page. Javadoc for that function strongly discourages using it directly, or its exposure as an EL variable. Notwithstanding this strong discouragement, I did not quite get it to work as expected. Either it is broken, or I'm missing something obvious about it and need clarification. Anyway, I will blog about it later separately, as and when I understand the reason for "incorrect" behaviour.

If you stumbled upon this post searching for how to enable PPR programmatically instead, information for that is available here.

ADF Best Practices Guide (Update to Pros and cons of various ADF configuration alternatives)

2008-11-17T00:12:00.000-08:00

As promised in the earlier post on this blog about this topic, I have been poking around for more material. I came across this very well written document, which many will find useful:

An Introduction to Oracle ADF Best Practices

Note however that this document was published more than 2 years ago. I'm sure the application developer community has learnt more about various configuration choices since then. As of now, I am not aware if any such updates have been distilled, or even whether any plans for update to this document are in the works. I'll try to find more information on this, and post an update here once I know anything concrete. Stay tuned.

View scoped managed beans

2008-11-10T02:56:00.000-08:00

This post examines a new scope for managed beans introduced in ADF 11 called "View Scope." In fact, going back to ADF 10, different users have attempted to implement their own viewScope such as this. I have personally been familiar with this new scope for quite a while (well, having been the guy responsible for requirement which led to its official implementation, since its inception) and I referred to it in one of my earlier posts on this blog.

As explained in the documentation for object scope lifecycles and Fusion page lifecycle, an object with lifecycle scope of viewScope is available until the ID for current view changes.

However, the note in both of these sections as of right now which states that "you cannot register a managed bean to this scope" is incorrect. I'm attaching a sample workspace which in fact illustrates the use of managed bean(s) registered with viewScope (along with couple of other scopes - pageFlowScope and requestScope). What you cannot do with viewScope unlike standard JSF scopes is to refer to managed beans registered with this scope with an EL syntax like #{myViewScopedManagedBean.foo}. You must use syntax explicitly dereferencing viewScope, such as #{viewScope.myViewScopedManagedBean.foo}. The sample workspace I attached illustrates this.

Another important section to pay attention to, in general for understanding where managed beans with various scopes should be registered and the effect this placement has on their behaviour is in table 18-1 here. Specifically, when intending to use view scoped managed beans in a task flow, they must be registered in the task flow definition file and not adfc-config.xml.

Using af:commandImageLink inside af:toolbar

2008-10-14T13:55:00.000-07:00

I just discovered a cool thing about the af:commandImageLink component, which I haven't seen explicitly documented. At least, the application developer's guide doesn't mention it, nor have I seen it in other blogs or code samples, so here goes.

The commandImageLink component can be included as part of an af:toolbar component as well. The section about toolbars in application developer's guide seems to mention usage of toolbar buttons as well as commandButton and commandLink inside them. Specifically, refer to following tip from that section:

Tip: Toolbars can also include command buttons and command links instead of toolbar buttons. However, toolbar buttons provide additional functionality, such as opening popup menus.

af:commandButton can also be associated with an optional icon. But, af:commandImageLink provides additional capability of optionally associating different icons on hover and depressed events. This functionality of potentially associating with 3 different icons can also be used with af:commandToolbarButton. As explained in the tip above, toolbar buttons come with extra potential functionality of popup menus. For users who don't care about extra baggage of popup menus, but desire a lightweight option inside af:toolbar (and potentially desire the option of being associated with multiple icons based on state), an alternative exists with af:commandImageLink.

Multiple ways of specifying width for af:table and precedence rules

2008-10-09T02:29:00.000-07:00

This post is about a minor functional idiosyncrasy I discovered while working on another problem. In fact, it is a corollary of configuration posted for an earlier blog entry.

The issue is that af:table has a dedicated attribute called width for specifying the width of the table. But like all other ADF Faces components, it also has an inlineStyle attribute which can be used for specifying the width (along with many other style settings). There is a slight difference in the syntax for specification for each of these, e.g. width="100%" as opposed to inlineStyle="width:100%;". Well, these can potentially be conflicting settings. If both of them are specified, which one is the real setting and what are the precedence rules? By doing a quick test, the functional specification for precedence is:

If width is specified through both "width" and "inlineStyle" settings, the "width" setting takes precedence and any width specified through inlineStyle is ignored.
Value in inlineStyle="width:whatever;" is only looked at, if no value specified in "width'".

Simple enough. But I'm afraid I haven't seen it functionally specified explicitly like this anywhere else, hence worth calling it out here with a dedicated post.

Using af:panelCollection with master-detail tables

2008-10-08T12:33:00.000-07:00

af:panelcollection is an aggregation component over components such as tree, table, treeTable for the purpose of standardizing menus, toolbars etc. I recently ran into some specific layout issues when using panelCollection with tables in a master-detail layout, which I feel are worth blogging.

Master-detail tables are typically shown one underneath another inside a panelGroupLayout component with vertical layout. With the default design-time configuration settings, I discovered that the layout for the detail table looked just plain ugly. Irrespective of any width and/or columnStretching attributes specified on the detail table, it looked squished with a forced horizontal scrollbar. My first instinct for fixing this was to surround the panelCollection inside a panelStretchLayout, thinking that its lack of stretchability inside panelGroupLayout was what was contributing to its ugliness. Unfortunately, playing around with all sorts of config settings with a panelStrechLayout thrown in ended up as a futile exercise. I must have spent close to a day poring over various component configuration documentations, trying different permutations and scratching my head wondering why none of them were working. Various conflicting constraints/conditions I was struggling with were:

panelStretchLayout should not be included inside panelGroupLayout as a general rule of thumb (unless specifying sizes in fixed pixels which typically shouldn't be done for applications to preserve browser compatibility)
panelGroupLayout layout=vertical can be included inside panelStretchLayout
panelCollection can be stretched inside a strechable parent, however if inside a panelGroupLayout, it won't be stretchable
af:table will fill up inside panelCollection if columnStretching specified

In the end, the solution I ended up with is far simpler, almost of the "duh!" variety. It was told to me by someone with prior knowledge of having worked with this use case. I haven't seen it well documented anywhere I searched, and feel it's worth blogging here, with the hope that it will save few hours for someone in the future. The key to the solution is that it does away with panelStretchLayout altogether, and specifies a width of 100% on both the panelCollection and contained table. That's it, it's that simple!! Here is an example layout:

<?xml version='1.0' encoding='US-ASCII'?>
<jsp:root xmlns:jsp="http://java.sun.com/JSP/Page" version="2.1"
          xmlns:f="http://java.sun.com/jsf/core"
          xmlns:h="http://java.sun.com/jsf/html"
          xmlns:af="http://xmlns.oracle.com/adf/faces/rich">
  <jsp:directive.page contentType="text/html;charset=US-ASCII"/>
  <f:view>
    <af:document>
      <af:form>
        <af:panelGroupLayout layout="vertical">
          <af:panelHeader text="Divisions">
            <f:facet name="context"/>
            <f:facet name="menuBar"/>
            <f:facet name="toolbar"/>
            <f:facet name="legend"/>
            <f:facet name="info"/>
            <af:panelCollection inlineStyle="width:100%;">
              <f:facet name="menus"/>
              <f:facet name="toolbar"/>
              <f:facet name="statusbar"/>
              <af:table var="row" width="100%" columnStretching="last">
                <af:column sortable="false" headerText="col1">
                  <af:outputText value="#{row.col1}"/>
                </af:column>
                <af:column sortable="false" headerText="col2">
                  <af:outputText value="#{row.col2}"/>
                </af:column>
                <af:column sortable="false" headerText="col3">
                  <af:outputText value="#{row.col3}"/>
                </af:column>
                <af:column sortable="false" headerText="col4">
                  <af:outputText value="#{row.col4}"/>
                </af:column>
                <af:column sortable="false" headerText="col5">
                  <af:outputText value="#{row.col5}"/>
                </af:column>
              </af:table>
            </af:panelCollection>
          </af:panelHeader>
          <af:panelHeader text="Product Groups">
            <f:facet name="context"/>
            <f:facet name="menuBar"/>
            <f:facet name="toolbar"/>
            <f:facet name="legend"/>
            <f:facet name="info"/>
            <af:panelCollection inlineStyle="width:100%;">
              <f:facet name="menus"/>
              <f:facet name="toolbar"/>
              <f:facet name="statusbar"/>
              <af:table var="row" columnStretching="last" width="100%">
                <af:column sortable="false" headerText="col1">
                  <af:outputText value="#{row.col1}"/>
                </af:column>
                <af:column sortable="false" headerText="col2">
                  <af:outputText value="#{row.col2}"/>
                </af:column>
                <af:column sortable="false" headerText="col3">
                  <af:outputText value="#{row.col3}"/>
                </af:column>
                <af:column sortable="false" headerText="col4">
                  <af:outputText value="#{row.col4}"/>
                </af:column>
                <af:column sortable="false" headerText="col5">
                  <af:outputText value="#{row.col5}"/>
                </af:column>
                <af:column sortable="false" headerText="col6">
                  <af:outputText value="#{row.col6}"/>
                </af:column>
                <af:column sortable="false" headerText="col7">
                  <af:outputText value="#{row.col7}"/>
                </af:column>
                <af:column sortable="false" headerText="col8">
                  <af:outputText value="#{row.col8}"/>
                </af:column>
              </af:table>
            </af:panelCollection>
          </af:panelHeader>
        </af:panelGroupLayout>
      </af:form>
    </af:document>
  </f:view>
</jsp:root>

I have seen some other proposed solution elsewhere, which has deeply nested panelStrechLayout elements. Instead of using a vertical panelGroupLayout, it uses a panelAccordian and showDetailItem. A visible disadvantage of such approach is that the text for showDetailItem adds yet another unnecessary title to the master-detail layout. Even if such text is omitted, the presence of showDetailItem is waste of unnecessary real estate. From a pure configuration perspective, such solution seems a bit convoluted to me due to the multiple levels of nested panelStretchLayout components. The approach presented here is far simpler.

Check out general guidelines on best practices for layout design.

Also, section 8.2.2 "Nesting Components Inside Components That Allow Stretching" from application developer's guide is worth going over.

Also see couple of latest layout guides:

Layout Pattern: Common Component in Form

Layout Pattern: Table with Header Left, Footer Right

Note that this trick of inlineStyle="width:100%;" cannot be arbitrarily applied to any component to force them to stretch. In particular, pay special attention to following tip from section 8.2.2 from above link:

Tip: Do not attempt to stretch any of the components in the list of components that cannot stretch by setting their width to 100%. You may get unexpected results. As stated previously, if you need one of these components to stretch, you need to wrap them in a component that can be stretched.

Since panelCollection is a component that can stretch, above tip does not apply to it in the presented sample. However, such inlineStyle configuration cannot be applied to other non-stretchable components such as panelBox.

Pros and cons of various ADF configuration alternatives

2008-10-07T00:37:00.000-07:00

Since summer, one of the common themes I've been thinking about while wearing the "application developer hat" is: ability in Oracle ADF to achieve identical functionality with multiple configuration settings. Since ADF is a very feature rich platform and encompasses multiple technology stacks, it is natural that there is overlap of functionality among different configuration approaches. While existing knowledge base is fairly solid w.r.t. documentation of functionality for specific configurations, I haven't found a lot of discussion about pros and cons of different configurations offering identical functionality. The question which has been fascinating me for past 2-3 months is: "If I'm an application developer new to ADF platform, when faced with multiple configuration alternatives, how do I decide which one to choose? What are the pros and cons of the different options?"

Case in point, one of my earlier posts here.

I present pros and cons of 2 approaches for the functionality of building RichTree for the SPECS object in that post.

write custom managed bean returning TreeModel using a complex hierarchical query
build multiple VOs and declarative databinding using non-hierarchical queries

I had to spend time building the alternate approaches and examine the pros and cons for myself. Here are few other design problems:

For communication among UI components in different regions on the same view, one can choose to use the producer/consumer communication model offered by contextual events. On the other hand, one can use a view scoped managed bean to set and get the payload being communicated, use an EL expression directly accessing the state of the managed bean e.g. #{viewScope.myCommunicationBean.payLoad} and use PPR among the different UI components for synchronization. The first approach is more declarative, however without spending time doing more experiments, it is not possible for an application developer to determine offhand if the second approach provides some other benefits. For example, maybe memory footprint or performance effiiciency?? I don't know the answer simply based on black-box knowledge of these functionalities.
Consider an application with 2 regions in a view - a tree on the left hand side, and master-detail on right hand side based on hierarchy type of node selection in the tree on left. One option heavy on declarative design-time would be using an af:switcher on the tree node based on its hierarchy type, and use different action links in each switch clause to generate payload for communication on right hand side. Another option would be a single tree node type with a single managed bean method as node selection listener. The selection listener could implement payload generation logic using a Java switch clause. Using the logic that a declarative solution provided by tooling should always be preferred as much as possible over one requiring writing custom managed bean code, the first option wins hands down. After all, the objective should be to minimize the amount of Java code required to be written by an application developer. But is that all there is to it? Are there any use cases at all, such that a functionality be better served by writing some cusom Java code in a managed bean, perhaps offering runtime efficiency benefits?

I'm sure there are multitudes of such examples all over various stacks of ADF functionality. I hope to spend more time in near future examining it in detail, but I'm tossing out this post here for brainstorming purposes. Consider this post more as a stirring the pot variety, rather than offering answers to specific questions. If anyone reading this has more insight into these issues, please post in my comments.

Determining RichTree node hierarchy type with tree node selection or row disclosure

2008-09-29T18:01:00.000-07:00

There is plenty of documentation available demonstrating selection handlers or row disclosure handlers for a node of an ADF RichTree. However, information on manipulation of the node data in these handlers is sketchy to come by. For a RichTree defined based on hierarchical data-binding with ADF BC objects, a specific use case is presented here: How to determine the node hierarchy type of a selected or expanded/contracted node?

For a RichTree definition such as below, assuming myFancyBean maps to a bean MyFancyBean.java, sample code for solving the use case above is presented. With a declarative databinding approach, an EL expression such as #{node.hierType.viewDefName} evaluates the node hierarchy type. However, such EL expression when evaluated inside a Java selection/row disclosure handler would not return the same result, due to not having appropriate context for the variable "node".

<af:tree
 value="#{bindings.myVO.treeModel}"
 var="node" rowselection="single" displayrow="selected"
 rowdisclosurelistener="{myFancyBean.handleRowDisclosure}">

Corresponding code in a Java handler for determining node hierarchy type is presented below. For the purpose of getting the point across, this code assumes that a tree node is being expanded. Tree node contraction is not handled in this code, however equivalent code can easily be written for handling contraction by using getRemovedSet instead of getAddedSet.

package com.whatever;

import oracle.adf.view.rich.component.rich.data.RichTree;

import org.apache.myfaces.trinidad.event.RowDisclosureEvent;
import org.apache.myfaces.trinidad.model.RowKeySet;

import oracle.adfinternal.view.faces.model.binding.FacesCtrlHierNodeBinding;

public class MyFancyBean {
  public MyFancyBean() {

  }


  //.....

  public void handleRowDisclosure(RowDisclosureEvent rowDisclosureEvent) throws Exception {
    Object rowKey = null;

    FacesCtrlHierNodeBinding rowData = null;
    String viewDefName = null;
    RichTree tree = (RichTree)rowDisclosureEvent.getSource();
    RowKeySet rks = rowDisclosureEvent.getAddedSet();
    if (rks != null) {
       int setSize = rks.size();
       if (setSize > 1) {
           throw new Exception("Unexpected multiple row disclosure row sets");
       }

       if (setSize == 0)
           return;
       rowKey = rks.iterator().next();
       tree.setRowKey(rowKey);
       rowData = (FacesCtrlHierNodeBinding)tree.getRowData();

       if (rowData.getHierTypeBinding() != null) {
           viewDefName =
                   rowData.getHierTypeBinding().getStructureDefName();
       }
    }
  }
}

Declarative databinding for lazy loading RichTree based on recursive View Objects

2008-09-29T13:51:00.000-07:00

There have been inquiries about ability in ADF for declarative databinding a RichTree component to a recursive View Object. A recursive VO is based on a hierarchical "START WITH ... CONNECT BY" SQL clause in Oracle DB, when a table in the schema has a self-referencing foreign key to itself. Such schema design may be used for describing hierarchical organization, or any deeply nested hierarchies.

An example of enquiry.

Solutions have been presented for custom building an ADF RichTree based on a complex hierarchical query. Such examples do not provide declarative databinding, and involve some Java coding.

Providing a lazy loading RichTree with custom Java coding involves lot more complexity, almost building your own custom databinding layer.

A solution is provided here for solving the requirement of a lazy loading RichTree based on self-referencing schema objects. For example, consider a database table SPECS for describing hierarchy of test suites, such that suites may have sub-suites nested upto an indefinite level. Tests are at leaf level in the hierarchy. The column "TYPE" in this table indicates whether a row corresponds to a SUITE or a TEST. The column SUITE_ID is the self referencing foreign key in this table, for referencing a sub-suite or test to its parent suite.

A hierarchical query solution would involve defining a View Object with expert mode SQL query such as below, followed by building a custom TreeModel for this VO and following the solution in AMIS blog link above.

SELECT
level, SpecsEO.ID, SpecsEO.TYPE, SpecsEO.DESCRIPTION
SpecsEO.SUITE_ID, SpecsEO.WEIGHT, SpecsEO.STATUS
FROM SPECS SpecsEO
START WITH SpecsEO.SUITE_ID IS NULL
CONNECT BY PRIOR SpecsEO.ID = SpecsEO.SUITE_ID

The alternate declarative solution proposed here does away with hierarchical queries altogether. It proposes defining 2 View Objects, a View Object for top level suites (or special case where tests are top level without being contained by any suites), and another View Object for rest of suites or tests. The top level VO breaks the recursion.

TopLevelSpecsVO :

SELECT
SpecsEO.ID, SpecsEO.TYPE, SpecsEO.DESCRIPTION,
SpecsEO.SUITE_ID, SpecsEO.WEIGHT, SpecsEO.STATUS
FROM SPECS SpecsEO
WHERE SpecsEO.SUITE_ID IS NULL

SpecsVO :

SELECT
SpecsEO.ID, SpecsEO.TYPE, SpecsEO.DESCRIPTION
SpecsEO.SUITE_ID, SpecsEO.WEIGHT, SpecsEO.STATUS
FROM SPECS SpecsEO

Two View links are defined:

between TopLevelSpecsVO and SpecsVO (TopLevelSpecsVO.ID = SpecsVO.SUITE_ID)
between SpecsVO and SpecsVO itself (Source SpecsVO.ID = Destination SpecsVO.SUITE_ID)

When defining databinding for RichTree, simply adding tree level rules based on above view links defines an accessor from view object SpecsVO to itself in the page definition file. This approach automatically takes care of displaying the RichTree with indefinite level of recursion. Apart from being fully declarative, another big advantage of this approach is performance. It provides a lazy loading RichTree by using caching provided by View Object layer.

The strongest advantage of this approach is when a hierarchical object such as this has a descendant relationship with some other object(s), and the RichTree needs to display this relationship through ADF BC backed databinding as well. For example, consider a master-detail relationship between a PRODUCT table and the SPECS table discussed above. Configuring databinding for RichTree between a PRODUCT table based VO and TopLevelSpecsVO would be a trivial exercise, facilitating a RichTree displaying hierarchy from products to test suites all the way down to tests.

To the best of my knowledge, no such declarative solution would be possible were the SPECS VO defined based on a complex hierarchical query, and a TreeModel based on it with a custom managed bean. I spent considerable amount of time investigating such possibility (simply for the sake of being a devil's advocate) and all such attempts were futile. There is simply no way in the current state of the product to mix-and-match ADF BC backed databindings with custom managed bean backed databindings in a declarative fashion. If you think you can prove me wrong, please post in my comments section and let me know how.

The only potential drawback of this approach which I can think of is an increase in the number of configuration objects. For each logical recursive schema object, it doubles the number of View Objects. However in my opinion (especially in the absence of out-of-the-box declarative databinding for a hierarchical object) this is a small price to play, compared to the elegance of a declarative solution with lazy loading.