ADF bug: missing af:column borders in af:table for IE7

There’s a rather obscure JDeveloper bug that only effects IE7, for af:columns in af:tables that show af:outputText fields based on dates that are null (phew, try and say that with a mouth full of wheaties). It occurs in 11.1.1.4.0 and 11.1.2.0.0 (and all versions in between it’s assumed).

In the previous picture from IE7 if you look closely, you’ll notice that the HireDate2 column has lost its border for the null entries. Note the other columns even when they are null, still have a border.

If we look under IE8 (or any other browser for that matter) we see the problem doesn’t occur at all:

The problem is being caused by 2 separate issues:

1) IE7 does not render borders for HTML table cells (ie. the tag) if the cell contains no data. This can be fixed if the cell contains a   tag.

2) ADF Faces RC includes the   tag for empty table cells, except for null date af:outputText fields who in addition have child tags that aren’t converter and validator tags.

To demonstrate the bug the MissingTableBorders application includes a simple test case. The application contains a View Object “EmployeesView” with a query based on the Oracle HR sample schema:

SELECT emp.EMPLOYEE_ID, 
       (CASE WHEN employee_id < 105 THEN first_name ELSE null END) AS FIRST_NAME1, 
       (CASE WHEN employee_id < 105 THEN first_name ELSE null END) AS FIRST_NAME2, 
       (CASE WHEN employee_id < 105 THEN hire_date ELSE null END) AS HIRE_DATE1, 
       (CASE WHEN employee_id < 105 THEN hire_date ELSE null END) AS HIRE_DATE2
FROM EMPLOYEES emp
WHERE emp.EMPLOYEE_ID BETWEEN 100 AND 110
ORDER BY emp.EMPLOYEE_ID

The query is designed to return two String columns that will have a mix of null and non null values, and two date columns that will also have a mix of null and non null values. If we run the Business Components Browser the data appears as follows:

Next is the code for our JSPX page “Employees.jspx” containing an af:table based on the VO from above. I’ve deliberately cut out the surroundings tags to focus on the tags that matter:

<af:table
    value="#{bindings.EmployeesView1.collectionModel}"
    var="row"
 rows="#{bindings.EmployeesView1.rangeSize}"
 emptyText="#{bindings.EmployeesView1.viewable ? 'No data.' : 'Access Denied.'}"
 fetchSize="#{bindings.EmployeesView1.rangeSize}" 
 rowBandingInterval="0"
 selectedRowKeys="#{bindings.EmployeesView1.collectionModel.selectedRow}"
 selectionListener="#{bindings.EmployeesView1.collectionModel.makeCurrent}" 
 rowSelection="single"
 id="t1">
  <af:column
      sortProperty="EmployeeId"
      sortable="false"
   headerText="#{bindings.EmployeesView1.hints.EmployeeId.label}"
      id="c5">
 <af:outputText value="#{row.EmployeeId}" id="ot4">
   <af:convertNumber groupingUsed="false" pattern="#{bindings.EmployeesView1.hints.EmployeeId.format}"/>
 </af:outputText>
  </af:column>
  <af:column 
      sortProperty="FirstName1"
      sortable="false"
   headerText="#{bindings.EmployeesView1.hints.FirstName1.label}"
   id="c4">
 <af:outputText value="#{row.FirstName1}" id="ot5">
 </af:outputText>
  </af:column>
  <af:column
      sortProperty="FirstName2"
      sortable="false"
   headerText="#{bindings.EmployeesView1.hints.FirstName2.label}"
   id="c3">
 <af:outputText value="#{row.FirstName2}" id="ot2">
   <af:clientAttribute name="ItemValue" value="#{row.FirstName2}"/>
 </af:outputText>
  </af:column>
  <af:column
      sortProperty="HireDate1" 
      sortable="false"
   headerText="#{bindings.EmployeesView1.hints.HireDate1.label}"
   id="c1">
 <af:outputText value="#{row.HireDate1}" id="ot3">
   <af:convertDateTime pattern="#{bindings.EmployeesView1.hints.HireDate1.format}"/>
 </af:outputText>
  </af:column>
  <af:column
      sortProperty="HireDate2"
      sortable="false"
   headerText="#{bindings.EmployeesView1.hints.HireDate2.label}"
   id="c2">
 <af:outputText value="#{row.HireDate2}" id="ot1">
   <af:convertDateTime pattern="#{bindings.EmployeesView1.hints.HireDate2.format}"/>
   <af:clientAttribute name="ItemValue" value="#{row.HireDate2}"/>
 </af:outputText>
  </af:column>
</af:table>

The code was created by JDeveloper by drag and dropping the VO from the data control palette, with the following changes:

a) There are two columns to display data from the first_name column. The only difference between them is the first_name2 column includes an additional af:clientAttribute tag.

b) There are two columns to display data from the hire_date column. Similar to the first_name columns, they only differ in the fact hire_date2 includes an af:clientAttribute tag.

When this page renders in the browser the generate HTML content for the rows of the table are as follows (note the formatting and the comment were added by me to make it easier to read):

<tbody>
  <!-- ---------- Record 100 ---------- -->
  <tr _afrrk="0" class="xxy ">
    <td style="width:100px;" nowrap="" class="xxv"><nobr>100</nobr></td>
    <td style="width:100px;" nowrap="" class="xxv"><nobr>Steven</nobr></td>
    <td style="width:100px;" nowrap="" class="xxv"><nobr><span id="t1:0:ot2">Steven</span></nobr></td>
    <td style="width:100px;" nowrap="" class="xxv"><nobr>17/06/1987</nobr></td>
    <td style="width:100px;" nowrap="" class="xxv"><nobr><span id="t1:0:ot1">17/06/1987</span></nobr></td>
  </tr>
  <!-- ---------- Record 101 ---------- -->  
  <tr _afrrk="1" class="xxy">
    <td nowrap="" class="xxv"><nobr>101</nobr></td>
    <td nowrap="" class="xxv"><nobr>Neena</nobr></td>
    <td nowrap="" class="xxv"><nobr><span id="t1:1:ot2">Neena</span></nobr></td>
    <td nowrap="" class="xxv"><nobr>21/09/1989</nobr></td>
    <td nowrap="" class="xxv"><nobr><span id="t1:1:ot1">21/09/1989</span></nobr></td>
  </tr>
  <!-- ---------- Record 102 ---------- -->  
  <tr _afrrk="2" class="xxy">
    <td nowrap="" class="xxv"><nobr>102</nobr></td><td nowrap="" class="xxv"><nobr>Lex</nobr></td>
    <td nowrap="" class="xxv"><nobr><span id="t1:2:ot2">Lex</span></nobr></td>
    <td nowrap="" class="xxv"><nobr>13/01/1993</nobr></td>
    <td nowrap="" class="xxv"><nobr><span id="t1:2:ot1">13/01/1993</span></nobr></td>
  </tr>
  <!-- ---------- Record 103 ---------- -->  
  <tr _afrrk="3" class="xxy">
    <td nowrap="" class="xxv"><nobr>103</nobr></td>
    <td nowrap="" class="xxv"><nobr>Alexander</nobr></td>
    <td nowrap="" class="xxv"><nobr><span id="t1:3:ot2">Alexander</span></nobr></td>
    <td nowrap="" class="xxv"><nobr>3/01/1990</nobr></td>
    <td nowrap="" class="xxv"><nobr><span id="t1:3:ot1">3/01/1990</span></nobr></td>
  </tr>
  <!-- ---------- Record 104 ---------- -->  
  <tr _afrrk="4" class="xxy">
    <td nowrap="" class="xxv"><nobr>104</nobr></td>
    <td nowrap="" class="xxv"><nobr>Bruce</nobr></td>
    <td nowrap="" class="xxv"><nobr><span id="t1:4:ot2" class="">Bruce</span></nobr></td>
    <td nowrap="" class="xxv"><nobr>21/05/1991</nobr></td>
    <td nowrap="" class="xxv"><nobr><span id="t1:4:ot1">21/05/1991</span></nobr></td>
  </tr>
  <!-- ---------- Record 105 ---------- -->  
  <tr _afrrk="5" class="xxy"><td nowrap="" class="xxv"><nobr>105</nobr></td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:5:ot2"></span></nobr> </td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:5:ot1"></span></nobr></td>
  </tr>
  <!-- ---------- Record 106 ---------- -->  
  <tr _afrrk="6" class="p_AFSelected p_AFFocused xxy">
    <td nowrap="" class="xxv"><nobr>106</nobr></td><td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:6:ot2"></span></nobr> </td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:6:ot1"></span></nobr></td>
  </tr>
  <!-- ---------- Record 107 ---------- -->  
  <tr _afrrk="7" class="xxy"><td nowrap="" class="xxv"><nobr>107</nobr></td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:7:ot2"></span></nobr> </td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:7:ot1"></span></nobr></td>
  </tr>
  <!-- ---------- Record 108 ---------- -->  
  <tr _afrrk="8" class="xxy">
    <td nowrap="" class="xxv"><nobr>108</nobr></td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:8:ot2"></span></nobr> </td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:8:ot1"></span></nobr></td>
  </tr>
  <!-- ---------- Record 109 ---------- -->  
  <tr _afrrk="9" class="xxy">
    <td nowrap="" class="xxv"><nobr>109</nobr></td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:9:ot2"></span></nobr> </td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:9:ot1"></span></nobr></td>
  </tr>
  <!-- ---------- Record 110 ---------- -->  
  <tr _afrrk="10" class="xxy">
    <td nowrap="" class="xxv"><nobr>110</nobr></td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:10:ot2"></span></nobr> </td>
    <td nowrap="" class="xxv"><nobr></nobr> </td>
    <td nowrap="" class="xxv"><nobr><span id="t1:10:ot1"></span></nobr></td>
  </tr>
</tbody>

If you look at records 100 to 104 all columns include data.

If we look at records 105 to 110 note:

a) The FirstName1 column when null includes a   to forcefully place a blank entry into the cell.

b) The FirstName2 column does exactly the same, remembering the FirstName2 column includes an additional af:clientAttribute tag.

c) For the HireDate1 column it also includes a  . Remember the HireDate1 column *does*not* include an af:clientAttribute tag.

d) For the HireDate2 column it *does*not* include an   tag, even though the HireDate2 values are null. Remember the HireDate2 column *does*include* an af:clientAttribute tag.

At this point we only see differing behaviour with af:outputText values in af:columns where they show Dates *and* the af:outputText includes an af:clientAttribute tag.

From my testing, converter and validator tags added to the af:outputText don't exhibit the same behaviour. However any other tag, not just adding an af:clientAttribute tag but even an af:clientListener as example will result in the missing   tag.

This in itself isn't an issue but when we consider IE7. If you render this page in IE8 the null date columns with an af:clientAttribute tag will still show the cell borders:

Yet in IE7 we get this:

While the issue is particular to IE7, the issue could be fixed by ADF Faces RC consistently generating the   entry as described in the HTML generated above.

In discussing this bug (12942411) with Oracle staff it turns out there is a broader base bug 9682969 where this issue occurs for more than just date columns. Unfortunately the problem is not easily fixable by Oracle as it requires the af:table and af:column components to know if the child component (in this example an af:outputText) will be null before it and the data it refers to is accessed and rendered.

The simple workaround as proposed by Oracle is to not render the child component at all if the data value is null, simply by including code similar to the following:

My thanks to Oracle staff who assisted in looking and resolving this issue.

A sample application can be downloaded from here.

ADF Faces - a logic bomb in the order of bean instantiations

One of my talented colleagues discovered an interesting ADF logic bomb which I thought I'd share here. The issue is with the instantiation order of ADF Faces scoped beans in JDev 11g when using Bounded Task Flows embedded as regions in another page.

Regular readers would be familiar that Oracle's ADF solution is built on top of JavaServer Faces (JSF). ADF supports bean scopes such as ViewScope, PageFlowScope and BackingBeanScope on top of the regular JSF ApplicationScope, SessionScope and RequestScope beans. Readers should also be familiar that the beans have a defined life (ie. scope) as detailed in the JDev Web Guide:

(Source: Oracle JDeveloper Web Guide 11.1.2.1 section 5.6 figure 5-11)

In specifically focusing on the life cycle of ADF PageFlowScope and BackingBeanScope beans, the guide states (to paraphrase):

1) A PageFlowScope bean for a Task Flow (either bounded or unbounded) survives for the life of the task flow.

2) A BackingBeanScope bean for a page fragment will survive from when receiving a request from the client and sending a response back.

The implication of this is when we're using Bounded Task Flows (BTFs) based on page fragments, it's typical to have a PageFlowScope bean to accept and carry the parameters of the BTF, and one or more BackingBeanScope beans for each fragment within the BTF.

Sample Application

With this in mind let's explore a simple application that shows this sort of usage in play. You can download the sample application from here.

The application's Unbounded Task Flow (UTF) includes a single SessionScope bean MySessionBean carrying one attribute mySessionBeanString as follows:

public class MySessionBean {

  private String mySessionBeanString = "mySessionBeanValue";

  public MySessionBean() {
    System.out.println("MySessionBean initialized");
  }

  public void setMySessionBeanString(String mySessionBeanString) {
    this.mySessionBeanString = mySessionBeanString;
  }

  public String getMySessionBeanString() {
    return mySessionBeanString;
  }
}

Note the System.out.println on the constructor to tell us when the bean is instantiated.

The UTF also includes a single page MyPage.jspx containing the following code:

In MyPage.jspx note the inputText control to output the SessionScope String from MySessionBean, and a commandButton to submit any changes. Second note the region containing a call to a BTF entitled FragmentBTF. However let's put the region aside for a moment and talk about the inputText and SesssionScope bean.

When this page is first rendered the inputText makes reference to the SessionScope variable. JSF doesn't pre-initialize managed beans, only on first access do they get instantiated. As such as soon as the inputText is rendered we should see the message from the MySessionBean constructor when it accesses the mySessionBeanString via the EL expression:

MySessionBean initialized

If we were to comment out the region, run this page and press the commandButton, we would only see the initialized message once, as the session bean lives for the life of the user's session.

Now let's move onto considering the region and embedded Bounded Task Flow (BTF) called FragmentBTF.xml. Points of note for the BTF are:

a) The Task Flow binding has its Refresh property = ifNeeded

b) And the BTF expects a parameter entitled btfParameterString, which takes its value from our SessionScope beans variable:

In terms of the FragmentBTF (as separate to the region/task flow binding) it has the following characteristics:

a) The BTFs has its initializers and finalizers set to call a "none" scope TaskFlowUtilsBean to simply print a message when the task flow is initialized and finalized. This will help us to understand when the BTF restarts and terminates.

b) The BTF has one incoming parameter btfParameterString. To store this value the BTF has its own PageFlowScope bean called MyPageFlowBean, with a variable myPageFlowBeanString to carry the parameter value.

public class MyPageFlowBean {

  private String myPageFlowBeanString;

  public MyPageFlowBean() {
    System.out.println("MyPageFlowBean initialized");
  }

  public void setMyPageFlowBeanString(String myPageFlowBeanString) {
    this.myPageFlowBeanString = myPageFlowBeanString;
  }

  public String getMyPageFlowBeanString() {
    return myPageFlowBeanString;
  }
}

Again note the System.out.println to help us understand when the PageFlowScope bean is initialized.

c) The BTF contains a single fragment MyFragment.jsff with the following code:

Inside the fragment are:

c.1) An inputText to output the current value for the MyPageFlowBean.myPageFlowBeanString. Remember this value is indirectly derived from the btfParamaterString of the BTF.

c.2) A second inputText to output the value from another bean, this time a BackingScopeBean which we consider next.

d) The BackingBeanScope bean is where we'll see some interesting behaviour. Let's explain its characteristics first:

d.1) The BackingBeanScope bean entitled MyBackingBean is managed by the BTF.

d.2) It is only referenced by the MyFragment.jsff within the BTF, via the inputText above in c.2.

d.3) The BackingBeanScope bean has the following code which includes the usual System.out.println on the constructor:

public class MyBackingBean {

  private String myBackingBeanString;
  private MyPageFlowBean myPageFlowBean;

  public MyBackingBean() {
    System.out.println("MyBackingBean initialized");
    
    myPageFlowBean = (MyPageFlowBean)resolveELExpression("#{pageFlowScope.myPageFlowBean}");
    
    myBackingBeanString = myPageFlowBean.getMyPageFlowBeanString();
  }

  public static Object resolveELExpression(String expression) {  
    FacesContext fctx = FacesContext.getCurrentInstance();  
    Application app = fctx.getApplication();  
    ExpressionFactory elFactory = app.getExpressionFactory();  
    ELContext elContext = fctx.getELContext();  
    ValueExpression valueExp = elFactory.createValueExpression(elContext, expression, Object.class);  
    return valueExp.getValue(elContext);  
  } 

  public void setMyBackingBeanString(String myBackingBeanString) {
    this.myBackingBeanString = myBackingBeanString;
  }

  public String getMyBackingBeanString() {
    return myBackingBeanString;
  }
}

d.4) It contains a variable myBackingBeanString which is referenced via an EL expression by the inputText explained in c.2.

d.5) However note that the constructor of the bean grabs a reference to the PageFlowScope bean and uses that to access the myPageFlowBeanString value, writing the value to the myBackingBeanString.

While this example is abstract for purposes of this blog post, it's not uncommon in context of a BTF for a backing bean to want to access state from the BTF's page flow scope bean. As such the technique is to use the JSF classes to evaluate an EL expression to return the page flow scope bean. This is what the resolveELExpression method in the backing bean does, called via the constructor and given to a by-reference-variable in the backing bean to hold for its life/scope.

At this point we have all the moving parts of our very small application.

Scenario One - Initialization

Let's run through the sequence of events we expect to occur when this page renders for the first time agaom, this time including the BTF-region processing as well as the parent page's processing:

1) From earlier we know that when the page first renders we'll see the SessionScope bean's constructor logged as the inputText in MyPage.jspx accesses mySessionBeanString.

MySessionBean initialized

2) Next as the region in MyPage.jspx is rendered, the FragmentBTF is called for the first time and we can see two log messages produced:

MyPageFlowBean initialized
Task Flow initialized

It's interesting we see the PageFlowScope bean instantiated before the Task Flow but this makes sense as the MySessionBean.mySessionBeanString needs to be passed as a parameter to the BTF before the BTF actually starts.

3) As the MyFragment.jsff renders for the first time, we then see the MyBackingBean initialized for the first time:

MyBackingBean initialized

So to summarize at this point by just running the page and doing nothing else, the following log entries will have been shown:

MySessionBean initialized
MyPageFlowBean initialized
Task Flow initialized
MyBackingBean initialized

In turn the page looks like this, note the value from the MySessionBean pushing itself to the MyPageFlowBean and the MyBackingBean:

The order the beans are instantiated and the values down the page all makes logical sense when we've an understanding of how the page is rendered.

Scenario 2 - The logic bomb

With the page now running we'll now investigate how there's a bomb in our logic.

Up to now if we've been developing an application based on this structure, we've probably run this page a huge amount of times and seen the exact same order from above. One of the problems for developers is we start and stop our application so many times, we don't use the system like a real user does where the application is up and running for a long time. This can hide issues from the developers.

With our page running, say we want to change the SessionScope bean's value. Easy enough to do, we simply change the value in the mySessionBeanString inputText:

When we press the "Page Submit" commandButton embedded in MyPage.jspx, given our understanding so far we'd expect the following behaviour:

1) As the session scope bean lives for the life of the user's session, we don't expect to see the bean newly instantiated.

2) Because the region's task flow binding refresh property is set to ifNeeded, and the source value of the btfParameterString has been updated, we expect the BTF to restart. As the content of the region are executed, based on our previous understanding logically we should see the following log entries:

Task Flow finalized
MyPageFlowBean initialized
Task Flow initialized
MyBackingBean initialized

(Note the Task Flow finalized message first. This is separate to this discussion but given the BTF is restarting, the previous BTF instance need to be finalized first).

Yet the actual log entries we see are:

MyBackingBean initialized
Task Flow finalized
MyPageFlowBean initialized
Task Flow initialized

And the resulting page looks like this:

Something definitely fishing is going on here. In the logs we see the BackingBean is now initialized before the previous Task Flow is finalized and before the PageFlowScope bean is instantiated. In turn on the running page we can see the "fishy" value has made it to the PageFlowScope bean but not the BackingBean. What's going on?

The explanation is simple enough based on 2 rules we've established in this post:

1) Firstly we know beans are only instantiated on access.

2) In returning to the Oracle documentation the scope of a BackingBean is:

"A BackingBeanScope bean for a page fragment will survive from when receiving a request from the client and sending a response back."

With these two rules in mind, when we consider the first scenario, the reason the BackingBean is instantiated after the PageFlowScope bean is because the contents of the BTF fragment are rendered after the BTF is started. As such the access to the BackingBean is *after* the PageFlowScope bean as the fragment hasn't been rendered yet.

With the second scenario, as the fragment is already rendered on the screen, the reason the BackingBean is instantiated before the PageFlowScope bean (and even the termination and restart of the BTF) is the incoming request from the user will reference the BackingBean (maybe writing values back to the bean) causing it to initialize at the beginning of the request as per rule 2 above. Officially "Erk!". Then as the BackingBean in its constructor references the PageFlowScope bean, it gets a handle on the previous BTF instance's PageFlowScope bean as the new BTF instance has yet to start and create a new PageFlowScope instance with the new value passed from the caller, and thus why we see the old value in the page for myBackingBeanString.

The specific coding mistake in the examples above is the retrieval of the PageFlowScope bean in the BackingBeanScope's constructor. The solution is that any methods of the BackingBeanScope that require the value from the PageFlowScope should resolve access to the PageFlowScope each time it's required, not once in the constructor. If you consider the blog post References to UIComponents in Session-Scope beans by Blake Sullivan you'll see a number of techniques for solving this issue.

Conclusion

Understanding the scope of beans is definitely important for JSF and ADF programming. But the scope of a bean doesn't imply the order of instantiation, and the order of instantiation is not guaranteed so we need to be careful our understanding doesn't make assumptions about when beans will be in/out of scope.

Readers who are familiar with JSF2.0 know that CDI and Annotations will work around these issues. However for ADF programmers CDI for the ADF scoped beans is currently not a choice (though this may change). See the Annotations section of the ADF-JSF2.0 whitepaper from Oracle.

Errata

This blog post was written against JDev 11.1.1.4.0.