[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-3008) Page fragment caching impossible with coarse-grained rendered attribute evaluation in JSF

[ https://jira.jboss.org/jira/browse/JBSEAM-3008?page=com.atlassian.jira.pl... ] Sebastian Hennebrueder commented on JBSEAM-3008: ------------------------------------------------ // copy of the post to the dev list 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 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira