Posts tagged ppr
ADF: (Automatic) Partial Page Rendering across Taskflows
0One of the great features of ADF is the easy out-of-the-box support for Partial Page Rendering (PPR) using the partialTriggers, autoSubmit and partialSubmit properties. And when things get a bit more complex there is a very easy API to do it programmatically. But what if
- you don’t know beforehand what attribute or column will change, or
- you don’t want to replicate this “Model logic” in the View layer (e.g. because you want to adhere to the Model-View-Controller pattern), or
- components are scattered across Taskflows (in which case you cannot use the declarative support and the programmatic approach is suddenly very hard)?
Fortunately, ADF has a solution: Automatic Partial Page Rendering (or Auto PPR). If you have used ADF with Business Components, you might have seen or used it already, but it is less obvious that you can also use it with ordinary Beans or Bean DataControls.
ADF 11g – implementing conditionally required input fields – by playing client side hide and seek
7The requirement I was dealing with today in ADF 11g Rich Client Components was the following: we have an input field that is required under certain conditions. Only when one of this cluster of fields has a value, is it required. Otherwise it is optional. The use case was that the fields represent a detail record. There does not need to be a detail record (optional) but if there is one (one of the fields in the detailrecord has a value), then certain fields are mandatory.
The desire was to dynamically set the required-ness of the inputText – depending on whether one of the items in the detail record cluster has a value or not. Dynamically means that when something changes with one of the items, the conditionally required item is immediately refreshed to either required or optional.
It turned out to be fairly easy to implement: the required attribute can be set using an EL expression that refers to a bean method. In the bean we can easily check the values of the other items and determine whether or not based on that assessment the inputText component is mandatory or not. By setting autoSubmit to true for all the items that determine the mandatoriness – and by adding the More >
ADF 11g – Validation of Uploaded Files with the inputFile component
Today we had a little issue with the inputFile component in ADF 11g, especially with its behavior after failed validation. Our situation: the inputFile component has autoSubmit set to true – so immediately after selecting a file in the browser dialog is the upload started in an asynchronous request. Validation is performed, either from validators or in a valueChangeListener (because I was too lazy to look up the syntax for a validator).
The behavior of the inputFile component is such that after the initial upload, the name of the uploaded file is shown as a read only value and the browse button is replaced by an update button: we can change the file, but not perform the initial upload anymore. When the user presses the update button, a small pop up appears in which we can browse for a file, click on the OK button to have it uploaded or click on Cancel to have the update aborted.
Unfortunately, when the file that was initially uploaded has failed validation, the OK button in this popup does not allow us to actually upload the newly selected file. The page continues to display the uploaded, invalid file and the update of that file to resolve the validation errors can not be More >
ADF Faces RC – Highlight partially refreshed areas to enlighten the user about automatic updates
One of the rich aspects of ADF Faces RC (and most Web 2.0/AJAX components) is functionality that performs Partial Page Refresh operations: actions by the user trigger asynchronous communication between browser and server that in turn may cause selected areas of the page to be refreshed. For example: entering a value may lead to a refresh of a derived value or a conversion of the entered value. Sometimes a single user action lead to refresh of multiple items and areas on the page. On other occasions, server push may cause items or page areas to be refreshed.
Without additional effort, these partial updates are subtle. They just happen. When the changes are small, the user will probably not notice the refresh taking place. He/she may see the new value, wondering where that came from. And that may be just fine. However, it could also be we like to make it clear to the user that and when items and areas have been refreshed. For example by highlighting the item or region in question immediately after the refresh takes place and having the highlight effect slowly fade away.
It turns out to be fairly easy to implement such a ‘highlight after partial refresh with fade away’ effect. More >
How to declaratively instruct ADF Faces RC to partially refresh other components upon an event
ADF Faces RC has built in support for AJAX and Partial Page Refresh. Through the autoSubmit and partialSubmit attributes, we can indicate that a value change or an action (button or link click) should trigger an asynchronous request (PPR request). Through the partialTriggers attribute, we can configure components to be refreshed in any PPR request that is initiated by the a component whose Id is listed in the partialTriggers attribute. So you can say that through the partialTriggers attribute, we register a component as PPR listener on all components listed in the attribute value.
Sometimes, developers would like to be able to do it the other way round. To specify on a component X which other components should be refreshed when X is initiating a PPR request. In this article, we will discuss a method for doing exactly that. (more…)
ADF 11g – Use the Change(d) Indicator to make AJAX originated value refresh explicit to the user
ADF 11g Rich Client Components have a facility called the Change(d) Indicator. The changed attribute is specified using a Boolean value or expression (typically the latter). When the expression evaluates to true, a visual indication is rendered on the component that signifies to the user that the item’s value has changed. While we can use this indicator in any way we see fit, a logical use case would be to highlight with this indicator any field that has been updated as a result of a partial page request/refresh – the AJAX style immediate update of portion of the page as a response to action by the user.
For example: when the temperature is entered in the Temperature Fahrenheit item (or changed using the Spin Controls), an auto submit is performed that in turn leads to an update of the Temperature Celsius item. Because of the changed attribute, the user can clearly identify the items that were automagically changed. Note: In this case we have used a custom skin that specifies another icon for the changed indicator (you will see the default icon later on in this article).
Recent Comments