Technical Articles relating to Oracle Development Tools and Frameworks

  • ADF
    January 18, 2013

Refresh Problems using Adaptive Bindings

Duncan Mills

In a previous article (Towards Ultra-Reusability for ADF - Adaptive Bindings)  I discussed how ADF Data Binding can be a lot more flexible that you would think due to the neat trick of being able to use expression language within the PageDef file to create bind sources that  can be switched at runtime.

As it happens my good buddy Frank Nimphius picked up the technique to use on a particular  project and hit a slight problem. If you change the results of the EL used in the binding - for example, you switch the base VO from Departments to Employees, things don't get refreshed correctly.  In fact what you see is that any attribute names that happen to match between the old and the new source will be correctly populated with the new data but the actual list of attributes will not be refreshed. The effect is that if you were using one of these bindings to populate a table, the "shape" of the table, in terms of its columns, would not change. 

No worries though, given that Frank is a clever chap he worked out the correct way to address this which is to simply call clearForRecreate() on the iterator binding.

 BindingContext bctx = BindingContext.getCurrent();
BindingContainer bindings = bctx.getCurrentBindingsEntry();
DCIteratorBinding iter = (DCIteratorBinding)

Thanks Frank! 

Join the discussion

Comments ( 2 )
  • Ushankah Wednesday, January 23, 2013

    Hi, Duncan!

    Could you tell please, how to apply this solution to custom iterator that is used in the <af:iterator in the absence of such binding on pageDef?

  • Duncan Wednesday, January 23, 2013

    I don't really understand the question. If you are using a conventional managed bean to provide the data for an af:iterator tag this is not using the ADF binding layer at all and so has nothing to do with adaptive bindings.

    In the case where you are wanting to set the value of an af:iterator, af:table etc. to one of a variety of possible managed beans then that's certainly possible. I'd probably set the actual El value of the af:iterator to a Map and then have the map key configure which source collection to use to populate the iterator or table.

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.