[seam-dev] Caching issues with JSF rendered attribute

[Dan Allen]

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 at laliluna.de> 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 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
>
>
>
>
> _______________________________________________
> seam-dev mailing list
> seam-dev at 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.