LarsBlog

Wrapping up my first WebSphere Portal project using the JSF implementation IBM have bundled with RAD 7.0 has left me with a bunch of random guidelines and recommendations for working with this version of JSF:

• Getter/Setter methods on a JSF managed bean may be called several times during a single render phase. Its important that this does not result in multiple expensive calls (ie to a database). Ideally, getters and setters should only return or set a value, not call business logic. If there is no option but to make an expensive call to retrieve an object for a getter, At the very least they should cache returned values.
• The default package name ("pagecode") that RAD uses for JSF page-code classes is ugly - Should change it (eg: com.something.ui.jsf) to match the rest of your UI code.
• IBM-JSF has bugs allocating ids at run-time for components that don't have an id specified in the JSP, so it's important to specify an ID for every JSF component.
• You can disable the auto-generating of page-code getters for each component in RAD's menu under Window -> Preferences -> Web Tools -> Faces -> Generate fields and getters? This should stop your page-code from getting horribly cluttered.
• Note that RAD's auto-generated getters for JSF components mentioned above are also slightly buggy in that they cache an instance of the component in the page-code bean. The problem with this is that some operations (like calling setValue() on the component instance) don't work properly if you have an instance of the component cached from a previous request. As a general rule (or at least for session-scoped backing beans) you really need to ensure you don't cache components, or use findComponentInRoot() directly.
• Don't use opening/closing tags for tags that don't have to contain anything, eg:
  <h:someTag/> rather than <h:someTag></h:someTag>
• Always use session scope for your List if iterating over it with a dataTable. Selecting an item from the List using a dataTable with a commandLink for example seems to require that this List stays in the session.
• Always use session scope for backing beans of the contents of AJAX-refreshed panels, otherwise you'll loose state between requests.
• Don't explicitly set or get request/session attributes (ie using session.setAttribute()), as JSF seems to sometimes remove session attributes it's not aware of. Always use JSF managed beans (RAD's provided PageCodeBase class provides a method resolveExpression() that you can use/modify to set the value of JSF managed-beans.
• Never put anything in a form that might be included as a POST parameter that is not a JSF component! Using plain-HTML inputs inside JSF forms seems to cause some nasty yet somewhat subtle bugs with IBM's JSF framework (under WebSphere Portal, anyway).
• Given there doesn't appear to be a way to specify an initialise action for a page (particularly true of the first page your application displays) - we had a tendency to create a getInitialisePage() method on page backing beans that performed whatever initialisation/data-retrieval was required for that page. This method would return an empty String and would be trigger by a <h:outputText value="#{pc_page.initialisePage}"/> call at the top of the JSP.

Oh, my final point has to be, if you have time to investigate using alternative, more up-to-date JSF implementations - do it! IBM's JSF seems to be based on an old version of Sun's Reference Implementation and some of the bugs we found seem to stem from this.