You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@myfaces.apache.org by "Leonardo Uribe (JIRA)" <de...@myfaces.apache.org> on 2011/06/03 21:13:47 UTC

[jira] [Resolved] (MYFACES-3167) UIComponent EventListenerWrapper optimizations

     [ https://issues.apache.org/jira/browse/MYFACES-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Leonardo Uribe resolved MYFACES-3167.
-------------------------------------

       Resolution: Fixed
    Fix Version/s: 2.1.1
                   2.0.7

> UIComponent EventListenerWrapper optimizations
> ----------------------------------------------
>
>                 Key: MYFACES-3167
>                 URL: https://issues.apache.org/jira/browse/MYFACES-3167
>             Project: MyFaces Core
>          Issue Type: Improvement
>          Components: JSR-314
>    Affects Versions: 2.0.6, 2.1.0
>            Reporter: Leonardo Uribe
>            Assignee: Leonardo Uribe
>             Fix For: 2.0.7, 2.1.1
>
>
> Our current implementation for EventListenerWrapper class inside UIComponent works well but it can be better.
> This wrapper is used by UIComponent.subscribeToEvent and unsubscribeFromEvent to handle the case when a listener is the same component, so when the state is restored, the component could be found using UIComponent.getCurrentComponent().
> The spec says that @ListenerFor annotations can be used for both components and renderers. Why EventListenerWrapper don't do the same trick for renderers? Since the rendererType does not change over component lifetime (just on init time), we can expect UIComponent.getCurrentComponent().getRenderer(facesContext) return the expected one without need to create it, right?
> Other reason to assume the previous trick for renderers, is renderer listeners are not registered for components that does not use the same renderer. This can be checked easily looking on ApplicationImpl.createComponent code.
> Additionally, EventListenerWrapper could take into account other cases where the listener implements StateHolde or PartialStateHolder, or even better it can assume on PSS it is not required to save info and restore the listener, because the listener is stateless.
> The effect of this optimization is h:outputScript and h:outputStylesheet will return null when saveState() is called and PSS is on, minimizing the state stored by state saving algorithm.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira