1. Don’t use any JSP tags in pages. No JSTL, no for loops, nada. The reasons are twofold, and the prohibition can easily be enforced by using facelets, which don’t use JSP at all.
1. The view technologies don’t play well together. JSP tags are rendered as they are encountered, whereas JSF tags are not rendered until the end of the request. Mixing the two can lead to surprising results.
2. JSF components automatically provide an excellent degree of separation between business logic and display logic with standard component attributes such as rendered, disabled, and value. If you think you need JSTL, you haven’t found the right component yet. If you think there isn’t one, write your own. JSF provides standard components that wrap all HTML components, and <h:dataTable> handles loops in a very clean way, so it is hard to imagine any necessary use of JSTL tags. If <h:dataTable> isn't good enough for youk, Facelets provides a generic iterator, <ui:repeat>.
2. Wrap ALL output text in a JSF tag (like <h:outputText>). This provides XSS checking and internationalization benefits.
3. Don’t write ANY HTML in your view templates. JSF components should handle all rendering, and CSS should handle anything you can’t do with component attributes. By avoiding HTML in view templates, you preserve device independence and avoid the need for a custom view template for each customer / customization.
4. Use a facelets template to set headers and footers rather than including these in each view template. Facelets gives you the best of JSF component model in combination with a Tiles / portlet-like approach to site customization.
5. Use properties bundles for all output text. Use <f:loadBundle> in your JSF view templates. In Java code, there are three ways to get a bundle:
1. FacesContext.getCurrentInstance().getApplication().getMessageBundle() to get the system bundle
2. Use the JSF Expression Language (EL) to reference a bundle named in the view template (not recommended as this probably introduces an unwanted dependency)
3. Use the Java native methods for properties lookups in any bundle.
6. Wherever possible, don't specify converters and validators in the view template. Instead, register your custom converter by class, and JSF will automatically invoke it when it encounters a property of that type in a value binding.
7. Don’t refer directly to any attributes or parameters in the Request or Sessions scopes. Instead, create JSF managed beans in one of these scopes to encapsulate the data you wish to store.
8. Always use <h:commandLink> instead of <h:outputLink> except when going to external sites. This way, your URLs get processed by the system-wide view handler implementation, which may be necessary for correct behavior in a portal environment or when you have custom view handler implementations installed for various security purposes.
9. Note that <f:verbatim> doesn't do cross-site scripting prevention, unlike all the other JSF tags. However, it is a performance enhancer, as anything between <f:verbatim> tags does not get stored in the state manager.

Use wrapper types (Integer, Long) rather than primitives (int, long) for all your getters and setters in managed beans. JSF likes nullable references.

public void processAction(ActionEvent event) throws AbortProcessingException {
UIComponent component = (UIComponent)event.getSource();
while (!(component != null && component instanceof HtmlTree)) {
component = component.getParent();
}
if (component != null) {
HtmlTree tree = (HtmlTree)component;
TreeNodeBase node = (TreeNodeBase)tree.getNode();
tree.setNodeSelected(event);
setAuthorBio(((ExtendedTreeNode)node).getLongDescription());
}
}

Sun's JSF implementation uses Cactus, JUnit, and HTMLUnit for its automated testing. We have extracted the testing framework from Sun's JSF implementation codebase and now offer it in this project.