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

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