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


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.

Reply via email to