Over on the ODTUG mailing list, Jason asked an interesting question:
I've got a JSP page built using JSTL that uses an ADF range binding to present the user with a read-only table that the user can scroll page by page. I want to give the user a button that they can press to refresh the data in the table to reflect any changes that have been made. When I do a regular Execute action to re-execute the query, the current row moves back to the first row. How can I achieve this refresh-but-stay-where-you-were functionality?
I'd recommend writing the following method in your ViewObjectImpl subclass for the view object in question:
public void refreshQueryKeepingCurrentRow()
{
Row currentRow = getCurrentRow();
Key currentRowKey = currentRow.getKey();
int rangePosOfCurrentRow = getRangeIndexOf(currentRow);
int rangeStartBeforeQuery = getRangeStart();
executeQuery();
setRangeStart(rangeStartBeforeQuery);
/*
* In 10.1.2, there is this convenience method we could use
* instead of the remaining lines of code
*
* findAndSetCurrentRowByKey(currentRowKey,rangePosOfCurrentRow);
*
*/
Row[] rows = findByKey(currentRowKey, 1);
if (rows != null && rows.length == 1)
{
scrollRangeTo(rows[0], rangePosOfCurrentRow);
setCurrentRowAtRangeIndex(getRangeIndexOf(rows[0]));
}
}
Then, by visiting the View Object editor and going to the Client Interface panel, we can shuttle this refreshQueryKeepingCurrentRow method name into the Selected list of methods available on the client interface for this view object.
When you add a custom method to the client interface of a view object or an application module, it appears in the Data Control Palette as an available method under the respective Operations folder in the tree for the component in question. Then, you can drag and drop this custom method as a button to your JSP page, and clicking the button will declaratively invoke the custom method.
How does it work? As highlighted in my ADF Data Binding Primer whitepaper, dropping the method from the Data Control palette onto your JSP page creates both the visual button, as well as an ADF action binding in your page's binding container. The action binding by convention is named the same as the method, so in this case it will be called refreshQueryKeepingCurrentRow. Its declarative properties will be automatically set to point to the method on the datasource on the data control. The button dropped into the page is named event_refreshQueryKeepingCurrentRow so that when it's clicked, it caused an event named refreshQueryKeepingCurrentRow to fire. By default, the ADF DataAction will handle an event by looking to see if there is an action binding by the same name as the event, and if so, firing invoking its action declarative. So, clicking the button causes the event to occur whose name matches the name of the action binding that is bound to the view object methods, and it all just happens without user-written code (other than the ViewObject instance encapsulated custom code above).
2:01:16 PM 
|
