Limitations: Faces Web applications

Here are several limitations to be aware of as you create your Faces Web applications.

 

Post backs to Faces JSP pages

Here is a general usage tip when you build Faces JSP pages. In some cases, post backs to a Faces JSP page might need to recreate the objects first used to first render the page. If there are arguments to the creation of that object, then they need to be available to the post back. You can do this by storing the arguments in a hidden input field on the form or as parameters on a link tag. In other words, the reevaluation of the rendered state has to match what it was the last time the page rendered. It is for this reason that you need to pass something back to create the match.

 

Faces JSP welcome pages and WAS v5.1

There are problems when you have a Faces JSP welcome page and are targeting a WAS v5.1 server. One workaround is to have a welcome page that is not a Faces JSP page and then do a forward to a Faces URL. Another workaround involves making sure that the Faces servlet processes the request before forwarding to the Faces JSP welcome page. You can do this by prefixing the URL with /faces/ or by changing the .jsp file extension to a .faces file extension. The Faces servlet modifies the URL to point to the JSP and does a forward.

 

Focus problem on fields displayed in Internet Explorer

There is a known problem in Internet Explorer with focus on certain fields that were created on Faces JSP Web pages. When focus is on a radio button, a check box, or a link, a focus rectangle does not appears around them in Internet Explorer. In fact, the field does have focus (which you can see when you press the space bar and it works correctly in the field). The workaround is to manually press TAB on the page to get field focus to work.