Working with the Seam Framework and RichFaces for over a year, I found their respective components work only for the simplest of HTML forms. Nested AJAX views cause all sorts of difficulties once you get into EL expressions for iterated components (e.g., from <rich:datatable>) within <f:subview>-named scopes that require usage of rich:element.

The biggest challenge has been to get each customized component within a view to render correctly, avoiding situations where the rendered="" attribute evaluates to an unexpected value as elements are still in the component tree even when rendered="" is evaluated to “false”. For example, the <c:if> test=”” expression is evaluated when the component tree is built, so if any variables within test=”” reference a render-time component attribute such as var=”” of <rich:datatable>, that EL statement may silently evaluate to null or false. You must always be conscious of the component tree’s lifecycle for each component type.

Another big problem is RichFaces’ rich:element() function not taking namespace into consideration, so the nearest id=”” component-matching sibling or even first match in the whole view will be returned. A parent <f:subview> will not be used unless you explicitly prefix the rich:element parameter with it.

The issue I had was <f:subview> instances nested in customized components when I would require an id=”” attribute definition for every usage of components. e.g., <customlibrary:customtag id="yourComponentId" .../>. This is too verbose when your goal should always be rapid development using concise solutions.

I found the best workaround was a JavaScript hack that takes into account how JSF generates the HTML markup of id=”” attributes on each DOM element sourced from the component tree. It is the clientId of each JSF component in the tree concatenated by the ‘:’ character. By truncating up to the last ‘:’, you can attain the parent subview namespace and then append the string parameter usually passed into rich:element() or rich:component(). For example, the oncomplete="" binding of <a4j:commandbutton>, the previous method to attain a local DOM reference:

becomes:

That fixes all the confusion with changing visibility of HTML elements or using jQuery animations to manipulate JSF components in a more general manner. It’s backwards to hardtype JavaScript to a specific view when you want reusable code.