Tuesday, July 17, 2012

Refresh ADF table after a popup message/confirmation

In this blog post, I am demonstrating a way to refresh the contents of an ADF table after a certain action (any CRUD operation) especially when a confirmation popup or message has to be displayed.

Just creating an invokeAction on the binding to refresh the table works if there are no popups or message dialogs on button action. However, if you have a situation to refresh the table AND display the popup, you will just have to do an additional config. There could be other ways to solve this, but I found the following approach easy to work with.

The solution is to disable the 'cacheResults' property of the iterator to which the ADF table is bounded to and ensure that an "invokeAction" executable is created on the binding to refresh it (say prepareModel stage or renderModel stage for example). To do this,
  • Go to the page definition file and edit the source view
  • Find the iterator to which the ADF table is bounded with
  • Add the additional property cacheResults and set its value to false
<iterator Binds="AdminVO1" RangeSize="25" DataControl="AppModuleDataControl"
              id="AdminVO1Iterator" CacheResults="false"/>

Let us find out why this additional config is required? Why does the invokeAction which is set to re-execute on page render does not work when a popup/message is displayed?

By default, whenever an ADF table is created on a datacontrol it cache the results in memory in order to save on performance. Let us see what ADF documentation has to offer in this regard; (Highlighted portions that is of importance to this case)

When a data control modifies a collection, the data control must instantiate a new instance of the collection in order for the ADF Model layer to understand that it has been modified. In other words, although some action in the client may change the collection, that change will not be reflected in the UI unless a new instance of the collection is created. However, for performance reasons, accessor and method iterators cache their results set (by default, the cacheResults attribute on the iterator is set to true). This setting means that the iterator is refreshed and a new instance of the collection is created only when the page is first rendered. The iterator is not refreshed when the page is revisited, for example, if the page is refreshed using partial page rendering, or if the user navigates back to the page.

Since the popup/message dialog is displayed on action and the page refresh is interrupted midway, the refresh is not actually happening on just invokeAction and the table displays the cached results. However, if the iterator is set to not cache results, in a way we are forcing it to execute again for fetching the results when the page is rendered after the popup/message dialog display.

No comments:

Post a Comment