Single Page Application: Single Page Application

Single Page Application: Single Page Application

While working on a Java™Server Faces (JSF) project for last 3+ years, I had the opportunity to use Facelets. What I most liked about Facelets was that it let create reusable composition components. Its really great advantage of converting a simple JSP into reusable component. I personally think if we don’t use Facelets with JSF, we might not get the most out of the JSF.

There might be serious problem from performance perspective, because of mismatch between JSP and JSF development. I would recommend to go through “Improving JSF by Dumping JSP” http://onjava.com/lpt/a/4919 by Hans Bergsten, author of JavaServer Faces.

JSF is a stateful UI component based framework. To maintain the state of components, JSF has to create and maintain a tree for the components in the server. The situation would be worst if screen is very complex and having too many UI elements (JSF component). If these trees are not controlled there could be memory leakage and excess consumption of memory by JSF Component tree only. JSF is very easy to use and implement in any project. But the framework is very complex and if we don’t understand the complexity, there could be serious issue in development/maintainers and in performance and scalability. So I would recommend have at least some experts in JSF who can work on optimization of usage of JSF in the project. There could be different area where we need to be very careful while using JSF.

1. Short component Id

When a HTML page is being rendered by JSF, a client IDs is being generated as the HTML ID. This client ID is the ID of the component itself prefixed with IDs that are inherited from a hierarchy of naming components that contain this component. All such IDs are separated by colons to form the client component ID, example

id="Form:tabs:0:datatable:0:_id283"

Because these prefixes are being used repeatedly in the HTML pages, the network traffic can be reduced by shortening this prefixes. This will reduce the amount of data to be transferred. For examples:

2. Facelets for dynamic includes

Facelets integration has a great feature called 'dynamic' includes, which allows the developer to conditionally control what tag content is compiled into the JSF component tree. can be used to dynamically include different content into the page depending on a bean property.

If this technique is not used, all tag content will be compiled into the component tree. The advantage of using the dynamic Facelets include mechanism is that the resulting JSF component tree can be made much smaller, consuming less server-side memory. Minimizing the size of the JSF component tree can have a large effect on server-side memory consumption as the JSF component tree usually accounts for the majority of memory consumed in an application.

3. Avoid component bindings

Component binding, easy and sometimes useful represents anti-pattern in JSF development, as it couples the view to the model in the application.

There are several things to consider when using component bindings. First, component bindings make it very difficult to refactor JSF pages. As the components are tied to the model, a change to the page may directly affect the model, and/or also require changes to the managed bean used for the binding.

The use of component bindings may also have the negative side-effect of possibly causing memory leaks with component tree management with Facelets and JSF.

4. Avoid using JSF components for static value.

Using pure HTML elements for any static value will reduce the length of the element id. The size of tree will be reduced a lot.

Java Server Faces best practices

While working on a Java™Server Faces (JSF) project for last 3+ years, I had the opportunity to use Facelets. What I most liked about Facelets was that it let create reusable composition components. Its really great advantage of converting a simple JSP into reusable component. I personally think if we don’t use Facelets with JSF, we might not get the most out of the JSF.

There might be serious problem from performance perspective, because of mismatch between JSP and JSF development. I would recommend to go through “Improving JSF by Dumping JSP” http://onjava.com/lpt/a/4919 by Hans Bergsten, author of JavaServer Faces.

JSF is a stateful UI component based framework. To maintain the state of components, JSF has to create and maintain a tree for the components in the server. The situation would be worst if screen is very complex and having too many UI elements (JSF component). If these trees are not controlled there could be memory leakage and excess consumption of memory by JSF Component tree only. JSF is very easy to use and implement in any project. But the framework is very complex and if we don’t understand the complexity, there could be serious issue in development/maintainers and in performance and scalability. So I would recommend have at least some experts in JSF who can work on optimization of usage of JSF in the project. There could be different area where we need to be very careful while using JSF.

1. Short component Id

When a HTML page is being rendered by JSF, a client IDs is being generated as the HTML ID. This client ID is the ID of the component itself prefixed with IDs that are inherited from a hierarchy of naming components that contain this component. All such IDs are separated by colons to form the client component ID, example

id="Form:tabs:0:datatable:0:_id283"

Because these prefixes are being used repeatedly in the HTML pages, the network traffic can be reduced by shortening this prefixes. This will reduce the amount of data to be transferred. For examples:

2. Facelets for dynamic includes

Facelets integration has a great feature called 'dynamic' includes, which allows the developer to conditionally control what tag content is compiled into the JSF component tree. can be used to dynamically include different content into the page depending on a bean property.

If this technique is not used, all tag content will be compiled into the component tree. The advantage of using the dynamic Facelets include mechanism is that the resulting JSF component tree can be made much smaller, consuming less server-side memory. Minimizing the size of the JSF component tree can have a large effect on server-side memory consumption as the JSF component tree usually accounts for the majority of memory consumed in an application.

3. Avoid component bindings

Component binding, easy and sometimes useful represents anti-pattern in JSF development, as it couples the view to the model in the application.

There are several things to consider when using component bindings. First, component bindings make it very difficult to refactor JSF pages. As the components are tied to the model, a change to the page may directly affect the model, and/or also require changes to the managed bean used for the binding.

The use of component bindings may also have the negative side-effect of possibly causing memory leaks with component tree management with Facelets and JSF.

4. Avoid using JSF components for static value.

Using pure HTML elements for any static value will reduce the length of the element id. The size of tree will be reduced a lot.

ICEFaces for next generation web application

Hi All, my name is Mohammed Meraj; I have more than 9 years of experience in JAVA-J2EE platform. I have been working on JSF for more than 3.5 years.

JSF is one of the fastest growing and stable UI component based framework and ICEFaces has contributed a lot to make JSF Component more rich and easy to use in complex projects. I had started using ICEFaces since 1.6.1 (2007) version.
I really appreciate the kind of improvement done in the ICEFaces by ICEsoft guys. Honestly when I had started using ICEFaces, it had lots of issues and struggle a lot (one fact could be due to new in JSF for me). But when you compare now, we can see a lot of differences in all respects whether its richness of UI components, performance efficient. Etc. most important thing is than even ICEFaces is open source, ICEsoft is constantly working to improve stable the ICEFaces component.

I will share my experience with ICEFaces and ICEsoft for only selected area which was challenging in our projects. Rest detail; we can find in http://icefaces.org.

Ajax Based UI Components: IceFaces provides a rich web presentation environment for Java Server Faces (JSF) applications that enhances the standard JSF framework and lifecycle with AJAX-based interactive features. Recently ICEFaces have introduced composite components which have lot of real world rich component that can be easily fulfilling complex requirement.

For standard component please visit: http://component-showcase.icefaces.org/component-showcase/sh owcase.iface

For composite component please visit: http://composite-component-showcase.icefaces.org/icefaces-co mposite-comps-showcase/showcase.iface


Direct-2-DOM (D2D): I like the most about ICEFaces is about D2D rendering. Let me explain a bit about Direct-2-DOM (D2D) rendering. ICEfaces employs a technique called 'Direct-2-DOM' rendering, or D2D for short, to achieve smooth incremental page updates to the browser. ICEfaces stores a copy of the DOM, which represents the browser presentation state in a tree structure, on the server. When the user interacts with the page, an Ajax call may be made to the server, resulting in a change to the application state, which in turn will cause the page to be re-rendered on the server. Once the page is re-rendered on the server, and before the response is sent back to the browser, ICEfaces differs the old and new DOM trees to create a DOM update, which comprises the essential changes to the page which need to be sent back to the browser. These DOM updates, when received by the browser, are then evaluated and the browser DOM is reconstructed and updated with the necessary changes.

The benefit of D2D in that when ever any field value changed the dependent field update automatically, we don’t need to explicitly refresh the dependent block this saves lot of code and complexity an other important benefit we get is optimized server to client data transfer, only changed data is transfered from server to client.

Concurrent DOM Views : ICEFaces also provide multi window concept (Concurrent DOM Views), where same screen can be access at same time. Let me explain a bit. In our project user can access same module more than once let say user wants open a screen to view some customer detail at the same time user also wants to create new customer detail, this could be easily possible with the help of Concurrent DOM Views concept of ICEFaces.


Preventing Double Submit: ICEFaces also handled one of the crucial and important requirement is preventing double submit. If this issue is not handled in any of the projects this could be serious issue from business perspective.

Ajax Push: For real time notification asynchronously for the application users.

Rich Themes: ICEFaces also provide rich and standard set of themes e.g. rime, xp and royale.

Great technical support: A lot of forum and experts are there to support you if you stuck any where.

Dont miss my next blog, on best practices and how to use JSF-ICEFaces in an optimized way from performance, scalability and maintainability perspective.