[seam-dev] Caching issues with JSF rendered attribute

[Jay Balunas]

Already tagged for follow up ;-)

On Mon, Jul 28, 2008 at 3:26 PM, Dan Allen <dan.j.allen at gmail.com> wrote:

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



-- 
blog: http://in.relation.to/Bloggers/Jay
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20080728/47b80a5f/attachment.html