Posts tagged ajax
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 >
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…)
In this article, we will continue a discussion on asynchronous processing started in a previous article that introduced asynchronous and parallel processing Java using Executors, Futures, Callable Objects and the underlying thread model in Java 5 and 6.
While a stand alone Java application – without UI – is a rare thing in my world, a Java Web application certainly is not. And performance, especially perceived performance, is pretty important in that world. The first page load is the most important measure I suppose for what the user feels is the performance of the web application. The fact that after the initial load, additional elements can be loaded into the page – asynchronously – is fine. The intial page load and the browser’s indication that the load is done (and the hourglass disappears) is what is most important for the happiness of the user.
We will see three stages in this article, of a very simple web page. It is a JSF (JavaServer Faces) page, that contains some very simple elements of which one displays an ‘expensive’ value – a value that takes some time to get hold of. Maybe because a database query is involved or web service is called. Whatever the cause, this one More >
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).