Skip to main content


Showing posts from June, 2011

Safely storing UIComponent reference in a managed bean

Always it's recommended not to bind the UIComponent with managed bean with higher scopes(view, session, pageFlow, application etc.). There are multiple reasons to justify this suggestion.
1. JSF components are not Serializable, so your managed bean may fail to serialize in high availability mode.
2. Leaving stale references of the component if the bean survives the life of the view/page etc.

If you really want to store a component reference in managed whose scope is higher than request, then there is utility class for your help - ComponentReference . You can take a look at org.apache.myfaces.trinidad.util.ComponentReference API to learn more. I should admit that I was not aware of this one till I learned about this from an application developer ;)

ComponentReference Usage:

private ComponentReference someUICompReference;

public UIComponent getSomeUIComponent(){
   return someUICompReference == null ?
            null : someUICompReference.getComponent();

public void setSomeUIComp…

Building programmatically managed business components - Part 1

I've noticed quite a lot of queries in the public forum on building programmatic entity object and view objects . Let me share an example on this subject which may help you in implementing such use cases quickly. You can see a sample from Steve as well on this topic - 132.Programmatic View Objects Showing Master/Detail Data. Even my example also follows the same approach, of course with some minor tweaks hare and there :-)

Why do you need programmatic entity and view Objects?

Consider a scenario where you may need to retrieve data from a custom data source (say using third party API for example) and may need to perform some data update later on. While realizing such use cases, you my still want to leverage the declarative development support provided by the JDeveloper for building list of values, entity caching and validation, declarative transaction support etc. Though ADF got binding support for Java services, its not as rich as ADF BC implementation. One possible option is to cu…

Building programmatically managed business components - Part 2

Putting in to action

We have seen the basic theory behind the execution of  entity and view objects in the first part of this article. In the second part , let us put the theory in to action.


You can download the sample workspace from here.
[Runs with Oracle JDeveloper (11g R2) + HR Schema]
Please note this example does not use any API specific to release, so you may be able to reuse the source classes in previous versions also.

A glance at the implementation

This example uses two model objects - Department and Employee. The 'Department' is based on DEPARTMENTS table and it follows usual entity and view object generation steps, whereas Employee is based on custom data source and the steps for generating programmatically managed Employee model object is given below.

Building base classes for your programmatic entity and view objects

While building a programmatic view or entity objects you may need to hook your code to perform CRUD (Create Read Update D…

What you may need to know about Target Data Source entry for your tree binding definition?

There are use cases where you may need to refresh different parts of the page when user navigates between table or tree components which uses tree binding. In most of the cases the UI bindings(Target Data Source or TargetIterator) which needs to refreshed may share same Key attributes as your tree or tree table bindings. In such cases you can leverage the declarative support from ADF model to refresh the target iterator through 'Target Data Source' property associated with the tree binding. This topic is documented in Fusion Developers Guide, please see 29.5.4 How to Use the TargetIterator Property

Note: If you have 'TargetIterator' set for tree binding, ADF binding layer will never try to execute the target iterator using the 'Key' attribute(s) of the selected row of the source iterator. Instead the binding layer may simply call setCurrentRowWithKey on the target iterator using the key from the currently selected tree node. It means that, to make this property(…

Declarative transaction support for your JPA data model

While playing around with new featured of release, noticed an interesting one on data control side - declarative support for building Transactional Data Control for the business services built using JPAs. It looks cool ! There are a couple of points you may need to be aware of when you try this one.

1. Your should not keep 'Auto Commit' option 'true' for Java Service Facade if you need to defer the transaction commit. If this flag is ON, transaction will get committed as part of each service invocation from client.

2. ADF binding layer will never request the EntityManager to manage your entities at run time. So its your responsibility to associate your detached entities with PersistenceContext by calling EntityManager::persist(...) or EntityManager.merge(...) through generated wrapper method from the service facade.

Generating Transactional Data Control for your Java Service Facade

If you are new to EJB and never used ADF binding support to build UI for JPA …

Globally setting the change event policy for all data bindings

The release of ADF has added a new configuration entry in adf-config.xml file to globally set the default change event policy for the all iterators in the application. Of course, developers can override the default setting at each binding level.

<adf-config xmlns="" ... <adf-adfm-config xmlns=""> <defaults changeEventPolicy="ppr" useBindVarsForViewCriteriaLiterals="true"/>

Creating Task Flow bindings on the fly

A very common demand from the community was support for adding regions at run time. The good news is that 11.1.2 release has support for adding regions dynamically which is now well supported by a task flow binding layer as well. Wow...excited? Please see
21.10 Configuring a Page To Render an Unknown Number of Regions in developers fusion developers guide to learn more about this topic. Let me give you a quick overview on the implementation. Its very easy.

1. Build the logic to return TaskFlowBindingAttributes list for dynamic task flows

First step is to build a managed bean to hold your business logic for building list of oracle.adf.controller.binding.TaskFlowBindingAttributes as shown in the following code snippet.

private List<TaskFlowBindingAttributes> taskFlowBindings = new ArrayList<TaskFlowBindingAttributes>(); public void buidTaskflowBindings(){ TaskFlowBindingAttributes tfBindAttr1 = new TaskFlowBindingAttributes(); tfBindAttr1.setId("regi…

Call custom JavaScript method during component initialization

If you need to invoke custom Java Script method during some specific UI(ADF Faces) component initialization, then this post is for you. Idea is to use ClientListenerSet::addBehavior(javax.el.ValueExpression) to associate a deferred value expression (referring a JavaScript method) with the UI component, which will be evaluated later when DOM is rendered on the page. Thanks to Gary Van Matre who shared this idea in an internal discussion forum

public void setSomeInputField(RichInputText inpField) {
this.inputField = inpField;
ClientListenerSet clientListenerSet = inputField.getClientListeners();
if (clientListenerSet == null) {
clientListenerSet = new ClientListenerSet();
clientListenerSet.addBehavior("new CustomCompBehavior()");


You can download the sample workspace from here.
[Runs with Oracle JDeveloper 11g R1 PS4(]

Why does programmatic refresh fail for child table when the parent table has immediate=true?

Story so far...
There is a master table with immediate=true and a custom selectionListener. An editable(clickToEdit) child table needs to be refreshed programmatically from master table's custom selectionListener.

<af:table id="masterTabl" immediate="true" selectionListener="#{MyBean.customSelectionHandlerForParentTable}" ... <af:table id="childTabl" partialTriggers="::masterTabl" editingMode="clickToEdit" ... public void customSelectionHandlerForParentTable(SelectionEvent selectionEvent) { RichTable childTable = getChildTable(); refreshChildTableCollectionModel() RequestContext.getCurrentInstance().addPartialTarget(childTable); }
Now the fun starts...Though everything looks perfect, child table fails to reflect the refreshed CollectioModel (which is updated from the SelectionEvent of master table). Child table just repaints the previously submitted values from UI as i…