Hopping from one Train Stop to the next, causes the old stop to reexecute its bindings

We have a page with several tabs within it. If you click tab 2, the bindings for both tab 1 (the starting point) and tab 2 get executed. If you then go to tab 3, the bindings for tabs 1, 2, and 3 get executed. The more tabs you visit the more crunching that goes on behind the scenes. It's obvious that we don't need tabs that we aren't currently viewing, to get executed, just the one that we have most recently clicked.

To avoid this, we have customized some of the ADF data control classes, namely DCTaskFlowBinding. What we have done, is added code to release the list of executables from a task-flow’s bindings when the task-flow is navigated away from. This avoids having its executables refreshed.

The underlying ISSUE:
As new train-stops are visited, the bindings for each of the train stops, which are task-flows in our case, are added to the main train stop task-flow's list of executables within it bindings. Each time you visit a new tab, or rather a new train stop, the bindings for the main task-flow get re-executed. This causes all of its executables, which basically are the bindings for each of the visited tabs' task-flows, to get executed as well. Which, as you may have figured, causes the entire tree of bindings to get refreshed. Since this main task-flow is a major part of our application, there are probably hundreds of iterators within this tree, especially after visiting each of the tabs. This was causing a major slow down.

The FIX:
Our solution to this problem was to simply release the old tab's executable bindings as it was navigated away from. There is a navigation listener on the main task-flow which contains the activityId of the currently selected train stop. Once a new train stop is selected, this listener gets called. The last part of the listener method calls cleanupBeforeRelease in the DCTaskFlowBinding class. What we have done is, customized the DCTaskFlowBinding class to, as a part of this method, release all of this task-flows's executable bindings. Releasing these bindings essentially removes them from the binding container itself, which prevents them from being executed when the top level task-flow navigates to a new tab. This old tab's bindings still get executed, however, it is much quicker since the costly executables have been released.

The CODE:

1. In DataBindings.cpx
   
   Replaced:
   

   <factory nameSpace="http://xmlns.oracle.com/adf/controller/binding"
   className="com.collectamerica.aquila.common.TaskFlowBindingDefFactoryImpl"/>

   
   
   with
   
   

   <factory nameSpace="http://xmlns.oracle.com/adf/controller/binding"
   className="com.collectamerica.aquila.common.CustomTaskFlowBindingDefFactoryImpl"/>



2. Create CustomTaskFlowBindingDefFactoryImpl.java and extend TaskFlowBindingDefFactoryImpl
   
   Within that class we basically replaced:
   
   DCTaskFlowBindingDef taskflowBindingDef = new DCTaskFlowBindingDef();
   
   
   with
   
   
   DCTaskFlowBindingDef taskflowBindingDef = new CustomDCTaskFlowBindingDef();
   
   
   to end up with:
   
   
   public class CustomTaskFlowBindingDefFactoryImpl extends TaskFlowBindingDefFactoryImpl {
   public CustomTaskFlowBindingDefFactoryImpl() {
   super();
   }
   
   /**
   * {@inheritDoc}
   * @param element {@inheritDoc}
   * @return {@inheritDoc}
   */
   public DCDefBase createDefinition(DefElement element)
   {
   // In our case there is only one object we can create but we still do
   // the check.
   if (element.getNodeName().equals(Constants.ENAME_TASKFLOWBINDING))
   {
   DCTaskFlowBindingDef taskflowBindingDef = new CustomDCTaskFlowBindingDef();
   return taskflowBindingDef;
   }
   return null;
   }
   }



3. Create a class named CustomDCTaskFlowBindingDef which extends DCTaskFlowBindingDef, and basically this changes the binding container class name to point to our own custom class that we'll create next:
   
   
   public class CustomDCTaskFlowBindingDef extends DCTaskFlowBindingDef {
   public CustomDCTaskFlowBindingDef() {
   super();
   }
   
   @Override
   public void init(HashMap initValues) {
   super.init(initValues);
   
   // Overide BindingContainer class name with our special TaskFlowBinding.
   mBindingContainerClassName = CustomDCTaskFlowBinding.class.getName();
   }
   }



4. Create a class named CustomDCTaskFlowBinding which extends DCTaskFlowBinding and override the cleanupBeforeRelease method and implement it as follows:
   
   
   public class CustomDCTaskFlowBinding extends DCTaskFlowBinding {
   public CustomDCTaskFlowBinding() {
   super();
   }
   
   /*
   * This method has been customized in order to release bindings which are no
   * no longer needed. You'll find that in the super's method,
   * cleanupBeforeRelease, that there is a TODO which states that exactly what
   * we're adding should be done. This will prevent these old bindings from being
   * reexecuted everytime we switch between task-flows, and in the specific case
   * this was originally done for, will prevent all previous tabs from reexectuing
   * their executable bindings when switching tabs.
   */
   @Override
   protected void cleanupBeforeRelease(String childViewPortId) {
   super.cleanupBeforeRelease(childViewPortId);
   
   //if this task-flow is being notified, it is because this task-flow is being
   // navigated away from, so release its executable bindings (the expensive ones)
   // which will get relisted when the page is actually displayed again
   List executables = this.getExecutableBindings();
   
   if(executables != null){
   for(int i=0; i<executables.size(); i++){
   Object oExec = executables.get(i);
   
   if(oExec instanceof JUFormBinding){
   JUFormBinding jExec = (JUFormBinding)oExec;
   jExec.release(DCDataControl.REL_ALL_REFS);
   }
   }
   }
   }
   }

An empty SelectOneChoice is not triggering the required validation error

We had a problem with a SelectOneChoice that had the required attribute set to true, but it never threw an error once the form was submitted. It turns out that LOV settings on the View Object were causing the problem. There is a checkbox to include a "No Selection" item.



Checking this box causes an empty space to be represented in the dropdown list. This means that a empty string is a selectable value. Since this is not the same as null, if it is the selected value, it considers this as fulfilling the requirement for a value to be selected. If you leave this checkbox unchecked, and do not set the value of the selectOneChoice when it is initially rendered, then you can have the selectOneChoice show up initially with no value showing/selected, and then if the user submits, they will get an error stating the a value must be selected. Also, you get the benefit of not being able to select a blank value, because as soon as the user selects a value, the blank is gone.

Disabling buttons based on table selection

The easiest way to do this is to simply put an EL expression in the disabled attribute of the button that checks the size of the table's selectedRowKeys. You would also need to set a partialTrigger on the button with the ID of the table. The only problem with this is that it requires a trip to the server to evaluate the expression. Our application is going to be used by customers that are going to have low bandwidth and therefore need as few trips to the server as possible. So, we had to come up with a way to disable our toolbar buttons on the client (i.e. through javascript). We knew that a panelCollection did this very thing, so we just needed to tap into the panelCollection's functionality in order to duplicate this behavior.

We also had a need to arrange the buttons on the toolbar differently than what the panelCollection allows for. So, using a template (to replace all of our current implementations of panelCollections) we overhauled the panelCollection to suit our needs.

We tapped into the AdfDhtmlPanelCollectionPeer and found two important methods, updateStandardMenuToolbarItems and updateRowSelectionContext. The first is called when a column is selected, and the second is called when a row is selected.

Our template basically hid the original toolbar and added one on top that we could customize as much as we wanted, one that gets updated by chaining our own custom methods onto the two mentioned above. I am sure there is a proper design pattern named for what we're doing; it's something that is done with the onload function in many apps. Anyway, here is the code that we used to get our client code called every time a row or column is selected on a table that is within our template (which of course includes a panelCollection):

/* Allows the 'extra' toolbar to function as if it is part of the
* panelcollection. */
function initGridScript() {
if (typeof AdfDhtmlPanelCollectionPeer.prototype.updateStandardMenuToolbarItemsORIG != 'function') {
AdfDhtmlPanelCollectionPeer.prototype.updateStandardMenuToolbarItemsORIG = AdfDhtmlPanelCollectionPeer.prototype.updateStandardMenuToolbarItems;

AdfDhtmlPanelCollectionPeer.prototype.updateStandardMenuToolbarItemsCustom = updateMenuButtons;

//Update the 'extra' toolbar's buttons when the normal toolbar is updated
AdfDhtmlPanelCollectionPeer.prototype.updateStandardMenuToolbarItems = function () {
this.updateStandardMenuToolbarItemsORIG();

if(typeof this.getDomElement().className != 'undefined'){
if (this.getDomElement().className.search('CustomGridWithToolbar') > -1) {
this.updateStandardMenuToolbarItemsCustom();
}
}
}

AdfDhtmlPanelCollectionPeer.prototype.updateRowSelectionContextORIG = AdfDhtmlPanelCollectionPeer.prototype.updateRowSelectionContext;

AdfDhtmlPanelCollectionPeer.prototype.updateRowSelectionContextCustom = updateTableButtons;

AdfDhtmlPanelCollectionPeer.prototype.updateRowSelectionContext = function () {
this.updateRowSelectionContextORIG();

if(typeof this.getDomElement().className != 'undefined'){
if (this.getDomElement().className.search('CustomGridWithToolbar') > -1) {
this.updateRowSelectionContextCustom();
}
}
}
}
}

The AdfDhtmlPanelCollectionPeer.prototype.updateStandardMenuToolbarItemsORIG = AdfDhtmlPanelCollectionPeer.prototype.updateStandardMenuToolbarItems; saves off the original functionality so that we can invoke it later.

The typeof AdfDhtmlPanelCollectionPeer.prototype.updateStandardMenuToolbarItemsORIG != 'function' ensures that we are not appending our own functions more than once.

The this.updateStandardMenuToolbarItemsORIG(); ensures the original functionality is invoked.

The check for 'CustomGridWithToolbar' ensures that we are only calling our custom code when the panelCollection is the one from our template.

This function, initGridScript(), is called at the bottom of the javascript file on which it is declared, and the javascript file itself included as part of the template. So, it gets called whenever the template is written out to the response.

The updateStandardMenuToolbarItemsCustom method disables/enables menu items based column selection. In updateRowSelectionContextCustom, the code checks the RichTable client component's getSelectedRowKeys() to disable and enable the buttons in the toolbar accordingly.

How do I tell if they clicked a row in the table versus its body?

In our app, we have a dblClick clientListener as a direct child of a table. If the user clicks a row, we want to show them the edit popup for that row, if they click in white space (i.e. the are beneath the rows), we want to create a new row and show the popup to edit that new row. The source for either click will be the table itself, however, the target will be what we are interested in. To ensure that our code remains cross-browser compatible, we'll use methods made available by client-side ADF.

From the ADF js file, I have plucked the following:

var agent = AdfAgent.AGENT, domEvent = evt.getNativeEvent();
var target = agent.getEventTarget(domEvent);
var tablePeer = table.getPeer();
var attrs = tablePeer.GetRowKeyAndRow(target,tablePeer.getDomElement());

If attrs is null, then the user clicked within the table body and not on a row. If attrs is not null then the user clicked on an actual row.

Where'd my frickin' log window go?

I lost my log window in JDev, and no matter how many times I hit 'View > Log', it never appears; found the answer to resurrecting it on Duncan Mills' site.

1. Shutdown JDev


2. Delete windowinglayout.xml. This file is in the o.ide folder under the jdeveloper system folder, system11.1.1.0.31.51.56.


3. Restart JDev

This file will get rebuilt with the layout defaults, which includes the log window, or any other window you may have misplaced, when JDeveloper restarts.

Determining and Verifying Relative Partial Trigger Ids

Getting a component to refresh based upon the actions or events generated by other components requires that the partial target (the component you want to be refreshed) declare the id (via a relative or absolute path) of the trigger component of which to listen for a partial submit. Sometimes, determining this path can be a guesstimate at best, especially if your page contains included fragments, regions, or templates. Generally, if your target and trigger are within the same jsp fragment or jsp page, you can use the 'Edit Property' dialog on the partialTrigger attribute. For those tricky cases, read on ...

The method which I've discovered works best for me is to use Firebug and ADF's client side 'findComponent' function.

Step 1: Be sure to have Firebug installed. I currently am using Firefox 2.0.0.16 with Firebug 1.0.5, though this should work with any version of Firefox\Firebug.

Step 2: Determine the client id, including the full naming container path, of your target. This can be done by opening the HTML tab of the Firebug console and doing a search for the component's declared id. If you have a component which is several naming containers deep, this can be a lot easier than tracing the path through the jsp pages. We'll call this the target id from here on.

page:tmplt:rgn:panCol:tableA

Step 3: Determine the id, including the full naming container path, of your trigger. Use the same method as in Step 2.

page:tmplt:buttonA

Step 4: Paste these two ids into a text file and determine their last point of commonality. In the example below, the target and trigger share 'page:tmplt' as their base path. This means that this part of the path can be ignored, because these components will be relative to each other at this point.

page:tmplt:rgnA:panCol:tableA [target]

page:tmplt:rgnB:buttonA [trigger]

Step 5: Determine what the relative path of the trigger from the target should be. This can be tricky, but at this point all you really need is a good guess that we can test in the next step. For this example we can see that the trigger is up two naming containers and then down one.

So, for the first naming container we climb up from the target, we begin our relative path with two colons (if we were to put only one, we would be signaling that our path is absolute, and should start from the page root. No colons would be signaling to search for other components that are under the same naming container path as the target).

::

gets us to -> page:tmplt:rgnA

(Keep in mind that findComponent really starts from the current component's parent naming container if it's not a naming container itself OR itself, if it is a naming container. In this case the target is not a naming container, so the search begins from 'panCol', the target's parent naming container.)

To get above the next naming container, we add another :

:::

gets us to -> page:tmplt

Now we are at our point of commonality, and we need to begin to traverse down the naming container path into a different branch. Appending the down stream naming container path gets us to the level of our trigger.

:::rgnB

gets us to -> page:tmplt:rgnB

Now we just need to append the id of the trigger component. My use of id here refers to the id attribute that is declared on the component in the jsp. The client id of the component includes the full naming container path, as we saw when searching for the component in Step 1.

:::rgnB:buttonA

gets us to -> page:tmplt:rgnB:buttonA

Step 6: Now we use the ADF javascript method, findComponent, to get a handle to the target component and verify that we have calculated the the relative client id accurately. Open up the console tab and pass in the target id as the only parameter to the findComponent function.

AdfPage.PAGE.findComponent('page:tmplt:rgnA:panCol:tableA');

This should return an object; in my local example this returns an AdfRichTable object. Now, from this object we will use the same function and pass in the relative path we determined in Step 4.

AdfPage.PAGE.findComponent('page:tmplt:rgnA:panCol:tableA).findComponent(':::rgnB:buttonA');

If this function returns our trigger, then we know we have the correct relative path, :::rgnB:buttonA, to assign as the value for the partialTrigger attribute on our target. If not, we can test other paths rather quickly by plugging in different trigger ids. Most of my errors are either too few or too many leading colons, and I can easily test those by using this function.

Sticky Popup Values

Most of the problems that I will post about come from the project on which I am currently working. This post will be about one that has plagued us since the early days of our project, one which we thought we had fixed on more than one occasion; popups holding on to stale data.

Let's say a user clicks a button to edit values in a given table, in our app we use a popup to display a form in which the user can update the data. The user can make changes and click 'Ok' to save or click 'Cancel' to dismiss the changes; both actions dismiss the popup. Our problem was that if the user used 'Cancel', which has its immediate attribute set to 'true' (so that the validation does not occur), the next time they request for the popup to be displayed, it will display the values that were in the popup which we dismissed. This means that if we were editing row A in the table the first time, then cancelled, then decided to edit row B, the values from row A would appear. And every subsequent showing and canceling of the dialog would display the values from row A.

The issue turns out to be that since we skip the validation phase of ADF lifecycle, the values never get submitted out of the JSF model into the ADF model. The values therefore remain as values waiting to be submitted and are subsequently never excused from the fields in the popup. These values then replace whatever data is being displayed from the current row. So, if we were to click 'Ok' in the popup, they would then replace the values of the current row, and the next time the popup would be shown, it would actually be displaying the values from the current row as we expect (now that there are no stale values, because they have finally been submitted).

The trick we used to work around this issue is to basically clear out these un-submitted values from fields in the popup. We do this by iterating over all of the editable components that are in the dialog within the popup and using resetValue(). We generally pass in the dialog as the rootComponent.

public void resetStaleValues(UIComponent rootComponent){
Iterator iter = rootComponent.getFacetsAndChildren();
while (iter.hasNext()) {
UIComponent component = iter.next();
if (component instanceof UIXEditableValue) {
UIXEditableValue uiField = (UIXEditableValue)component;
uiField.resetValue();
}
resetStaleValues(component);
}