[
https://issues.apache.org/jira/browse/TRINIDAD-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1368.
---------------------------------------
Resolution: Fixed
TRINIDAD-1385 was opened for the regression
> Backport JSF 2.0 Component Tree Visiting and Optimize PPR Rendering
> -------------------------------------------------------------------
>
> Key: TRINIDAD-1368
> URL: https://issues.apache.org/jira/browse/TRINIDAD-1368
> Project: MyFaces Trinidad
> Issue Type: Improvement
> Affects Versions: 1.2.10-core
> Reporter: Blake Sullivan
> Assignee: Matthias Weßendorf
> Priority: Blocker
> Fix For: 1.2.11-core
>
> Attachments: JIRA_1368_12101.patch, visit.zip
>
> Original Estimate: 336h
> Remaining Estimate: 336h
>
> JSF 2.0 will add the ability for applications to visit all or a subset of the
> components in the component Tree in context using a visitTree function in a
> similar manner to how invokeOnComponent works with the following improvements:
> 1) For a single component, visitTree is faster than invokeOnComponent because
> visitTree avoids most calls to getClientId() on the traversed components
> 2) For multiple components, visitTree can visit all of the components in a
> single pass, avoiding replicating the work to setup and teardown the
> component contexts when visiting. In addition, visitTree guarantees the
> relative ordering of the component visits
> 3) visitTree supports optionally skipping non-rendered components, matching
> the visiting behavior of the JSF phases.
> 4) visitTree supports components and renderers that set up different or
> additional context when visiting during the encoding phase
> With a few improvements, this visitation scheme can be extended to support
> optimizing partial page rendering. Trinidad currently implements partial
> apge rendering by performing a full render of the component tree (with
> optimizations for NamingContainers with no targets) and discarding the
> results of the content outside of the partial targets. This is inefficient
> because the unrendered components still generate their markup, more
> expensively, they continue to evaluate the EL and execute the models
> necessary to generate that content. Thus, on a large complicated page, it is
> not especially faster (on the server) to render a small portion of the page
> than a large portion (with the exception of the NamingContainer optimization
> which does typically avoid executing tables). This limitation is one of the
> main performance issues with PPR (the other is the need to re-execute the JSP
> in JSP environments)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
