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

Jay, This would be an excellent candidate for an experiement to conduct with the performance infrastructure...not that you really needed the reminder, but just thinking outloud. -Dan On Mon, Jul 28, 2008 at 2:59 PM, Sebastian Hennebrueder <usenet(a)laliluna.de&gt; wrote: > 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 > -- Dan Allen Software consultant | Author of Seam in Action http://mojavelinux.com http://mojavelinux.com/seaminaction NOTE: While I make a strong effort to keep up with my email on a daily basis, life and work come first and, at times, keep me away from my mail for a while. If you contact me, then don't hear back for more than a week, it is very likely that I am excessively backlogged or the message was caught in the spam filters. Please don't hesitate to resend a message if you feel that it did not reach my attention. _______________________________________________ seam-dev mailing list seam-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/seam-dev