Re: [seam-dev] Caching issues with JSF rendered attribute

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(a)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 _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev