Partial Page Refresh (PPR) Support in JViews 8.5
Since JViews 8.5 we have enhanced our JSF components to completely support PPR. This is an important feature expected by our customers. Many questions have been asked around this new feature:
Let’s go into more details for each of the topics. We suppose you are familiar with JSF technologies. At least you know how a “Hello World” JSF application works.
What is Partial Page Refresh?
When working with JSF to build Web applications, your JSF pages are composed of JSF components. Take an example, you have a JSF page composed of 5 JSF components. When the JSF page is requested by any Web browser, the 5 JSF components will be rendered to HTML and sent to the browser. When users submit data to the server and request a refresh of the page, all 5 JSF components will be rendered again and resent to the browser. The entire HTML page is refreshed even if only one of the 5 components needs to be updated because the remaining 4 JSF components are quite static. You can see now the inconvenience of a Full Page Refresh.
Partial Page Refresh gives you the ability to update a subset of the JSF components. For the above example, if only one of the JSF components has been changed, you need to only re-render one component and send just the one component to the browser. You will see only part of the HTML page refreshed not the entire page. This technique has 2 advantages: the first is to reduce network traffic and improve the performance of the Web applications; the second is to improve visual comfort because only a part of the HTML page will be refreshed.
JSF PPR and Ajax
What is the difference compared to pure Ajax technologies? This is an interesting question because Ajax has also been introduced to update subsets of HTML pages. The difference is that Ajax is designed to work at a very low level. With Ajax, you can refresh a property of a given HTML element, such as the label of the button. With JSF PPR, you are working at the JSF component level. The minimum refreshable unit is a JSF component that might be composed of several HTML elements. This means that you can get very good performance with AJAX if you need to refresh only a very small part of the HTML page. Note that JSF PPR frameworks are usually implemented based on Ajax technologies.
The advantage of JSF PPR is at the design and development level, since it allows Rapid Application Development (RAD). You can create PPR Web applications very quickly by composing standard JSF components. In JViews 8.5, we provide both JSF PPR features for RAD and also Ajax features for performance purposes.
JSF PPR Frameworks
With Trinidad and RichFaces, you can specify explicitly at design time which components can trigger a partial refresh and which components can be refreshed. For example, let’s say that when you click a button you want a text field to be refreshed. The button is called the trigger component and the text field is called the target component. The target components are usually chosen at design time when authoring the JSF pages. However, target components can also be chosen at runtime when rendering the JSF page. These are tasks for advanced developers.
Knowing explicitly which ones are target components is helpful when rendering JViews JSF components. Because we need to render a JViews JSF component differently, depending on whether it is rendered for the first time or it is requested to be refreshed partially. You will see later why we need to distinguish these 2 situations.
ICEfaces has a very unique approach to handling PPR requests. At design time, i.e. when you compose your JSF pages, you can not specify which components are triggers and which ones are targets. All components are potentially triggers and targets. ICEfaces uses its direct-to-DOM rendering technique to determine dynamically at runtime which components should be updated. This may seem unusual, but it gives great flexibility to JSF application developers. However, JSF components providers like us need to do much more work to support this flexibility. The good news is that we have done this hard work for JViews 8.5. JViews JSF components can be used as any other ICEfaces native components.
Another particularity of ICEfaces is its server-side initiated rendering. This allows pushing updates from the server to the browsers. JViews 8.5 JSF components works fine within the ICEfaces push lifecycle.
JViews JSF Components Refactoring to Support PPR
JViews JSF components were initially designed to work in a static way within an HTML page. They were not initially designed to be updated after the HTML paged has been loaded.
Some JViews JSF components, such as a <jvd
Developing PPR JViews Web Applications
In JViews 8.5, JSF components have been refactored for supporting PPR without breaking the compatibility with previous versions. This gives developers flexibilities to add PPR features to their existing Web applications or to create new PPR Web applications.
In case you want to create new Web applications and want to benefit from PPR features, we suggests you develop your application with one of the supported PPR frameworks mentioned above. You can choose the framework of your preference that matches the functionality of your requirements. On the JViews side, Trinidad and ICEfaces are fully supported. JViews 8.5 supports RichFaces also, but has some limitations under Ajax mode. We have planned to fully support RichFaces for the next release.
In case you have developed your JSF applications with a previous version of JViews, you will be able to benefit immediately from the PPR features if you develop with one of the PPR frameworks mentioned above. If you develop with another JSF framework that does not support PPR at all, you won’t be able to benefit from the JViews PPR features. However, this does not mean that you have no choice other than doing a full page refresh, because the JViews JSF components have great Ajax features and can update themselves efficiently without invoking a full page refresh.