You should have talked to me, since i was working on the same thing.
-- Blake Sullivan
On Jul 27, 2009, at 9:13 PM, Andrew Robinson (JIRA) wrote:
[ https://issues.apache.org/jira/browse/TRINIDAD-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson updated TRINIDAD-1368:
--------------------------------------
Attachment: TRINIDAD-1368.trunk.diff
TRINIDAD-1368.1.2.11.4.diff
I really would like this to be fixed. Here is a proposed patch to
1.2.11.4 and Trunk. I would like to have it be reviewed before
committing it, especially with the UIXNavigation and its sub-classes
(For example, should undisclosed row keys be visited?)
Thanks
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
Attachments: JIRA_1368_12101.patch,
TRINIDAD-1368.1.2.11.4.diff, TRINIDAD-1368.trunk.diff, 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.
