[seam-dev] Caching issues with JSF rendered attribute

Sebastian Hennebrueder usenet at laliluna.de
Mon Jul 28 14:59:00 EDT 2008


Christian Bauer schrieb:
> If any JSF guru knows how to control rendered="true|false" evaluation 
> better, that would be useful:
>
> http://jira.jboss.com/jira/browse/JBSEAM-3008
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
Hello,

far away from being a guru of anything but I looked through the code.

Related to thie JBSEAM-3008 and the posting on 
http://seamframework.org/Documentation/TuningTheSeamWebsite

I evaluted JSF reference implementation 1.2.04

A component extending from UIComponentBase has a number of JSF phase 
handler.
processRestoreState
processDecodes
processValidators
processUpdates
processSaveState

a get request is only calling processSaveState but a post request is 
calling everything

The implementations are more or less iterating through the childs and 
calling the child handlers

Three methods (
processDecodes
processValidators
processUpdates
) are calling isRendered which in turn leads to an EL resolution.

In totally isRendered is called at least 5 times before an element is 
rendered. Calls are not cached and the EL is evaluated every time.
Calling methods are encodeChild,encodeBegin/encodeEnd/encodeChildren and 
a super class + 3 if the request is a post and the component extends 
UIComponentBase

There are two consequences: one for a proper cache implementation and 
one for performance

1) cache
To have a proper cache implementation our cache component needs to 
overwrite at least phase listener
processDecodes
processValidators
processUpdates
with an empty implementation. This will block all following updates as 
JSF is always running through the object tree. As a consequence the 
cached fragment should not be a form. The content will not be updated, 
even if it is not yet cached. processSaveState and processRestoreState 
should not be overwritten. It might be slightly inefficient but these 
methods fill the component tree we need to cache.

Actually, I wanted to create a patch but where is the source for 
HtmlCache. It seams not to be in seam-trunk. Anyway, just overwrite the 
three methods and don't delegate to the parent class but leave it empty.


2) performance
This is not related to the cache but a general JSF problem.
In the class org.jboss.seam.ui.util.cdk.RendererBase add two lines to 
evaluate the rendered expression
and call setRendered and set the result of the evaluation. This will 
reduce the calls for all components using this renderer to one call.

It would reduce the rendered EL calls by 80 % . The question is, if we 
will see any side effects.  If no components are doing funny things, it 
should work. I would propose that we carefully test this in different 
applications.

 public void renderChildren(FacesContext facesContext, UIComponent 
component) throws IOException {
    if (component.getChildCount() > 0) {
      for (Iterator it = component.getChildren().iterator(); 
it.hasNext();) {
        UIComponent child = (UIComponent) it.next();
// here the two lines
        boolean rendered = child.isRendered();
        child.setRendered(rendered);
        renderChild(facesContext, child);
      }
    }


Best Regards

Sebastian Hennebrueder
----
www.laliluna.de
Training, Tutorials and Java Development







More information about the seam-dev mailing list