Saturday, June 5, 2010

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 JSPhttp://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:

  1. 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.

  1. 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.

  1. 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.

No comments:

Post a Comment