[
https://issues.apache.org/jira/browse/TRINIDAD-1368?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Blake Sullivan resolved TRINIDAD-1368.
--------------------------------------
Resolution: Fixed
Fix Version/s: 1.2.13-core
Fixed in revision 908215 on Trunk and revision 908149 in 2.1.12.2
The first problem we have had is that components need to separate the contex6
setup and teardown needed to process their children from the context setup and
tear down of the components themselves. For example, consider a composite
component that establishes an EL context for its children--that context should
only be setup when the children are being processed, not when the component is
processing its own attributes.
In the case of encoding, we want to delegate to the Renderer to ensure that the
setup and teardown of context for child processing is consistent between
optimized rendering using tree visiting and full rendering traversals.
The second problem was that UIXComponent.setUpEncodingContext was named
differently than all of the other set up methods. I've made the spelling
consistent (which after a quick check of the dictionary is consitently wrong
through out Trinidad setup as a compound word is a noun and as a verb is two
words, so it should have been setUp. Drat!) and temporarily left a final
deprecated version in that I will whack shortly.
The third issue is that iterating components often want to modify only the
manner in which their data is iterated over. To simplify this, we add a hook
visitData() to UIXCollection.
-- Blake Sullivan
UIXComponent:
/**
* Hook for subclasses to override the manner in which the component's children
are visited. The default
* implementation visits all of the children and facets of the Component.
* <code>setupChildrenVisitingContext</code> will have been called before this
method is
* invoked and <code>tearDownChildrenVisitingContext</code> will be called
after.
* respectively. If the purpose of this visit was to encode the component and
the
* component uses a CoreRenderer, the CoreRenderer's
* <code>setupChildrenEncodingContext</code> and
<code>tearDownChildrenEncodingContext</code>
* will be called before and after this method is invoked, respectively.
* @param visitContext the <code>VisitContext</code> for this visit
* @param callback the <code>VisitCallback</code> instance
* @return <code>true</code> if the visit is complete.
* @see #setupChildrenVisitingContext
* @see #tearDownChildrenVisitingContext
* @see
org.apache.myfaces.trinidad.render.CoreRenderer#setupChildrenEncodingContext
* @see
org.apache.myfaces.trinidad.render.CoreRenderer#tearDownChildrenEncodingContext
*/
protected boolean visitChildren(
VisitContext visitContext,
VisitCallback callback)
/**
* <p>Sets up the context necessary to visit or invoke the children of a
component for all phases.
* </p>
* <p>The default implementation does nothing.</p>
* <p>If a subclass overrides this method, it should override
* <code>tearDownChildrenVisitingContext</code> as well.</p>
* <p>It is guaranteed that if <code>setupChildrenVisitingContext</code>
completes
* <code>tearDownChildrenVisitingContext</code> will be called for this
component</p>
* @param context FacesContext
* @see #visitChildren
* @see #tearDownChildrenVisitingContext
*/
protected void setupChildrenVisitingContext(@SuppressWarnings("unused")
FacesContext context)
/**
* <p>Tears down context created in order to visit or invoke the children of a
component
* for all phases.</p>
* <p>The default implementation does nothing.</p>
* <p>A subclass should only override this method if it overrode
* <code>setupChildrenVisitingContext</code> as well</p>
* <p>It is guaranteed that <code>tearDownChildrenVisitingContext</code> will
be called only after
* <code>setupChildrenVisitingContext</code> has been called for this
component</p>
* @param context FacesContext
* @see #setupChildrenVisitingContext
* @see #visitChildren
*/
protected void tearDownChildrenVisitingContext(@SuppressWarnings("unused")
FacesContext context)
CoreRenderer
* <p>
* Called before rendering the current component's children in order to set
* up any special context.
* </p>
* <p>If <code>setupChildrenEncodingContext</code> succeeds then
* <code>tearDownChildrenEncodingContext</code> will be called for the same
component.
* </p>
* <p>The default implementation does nothing</p>
* @param context FacesContext for this request
* @param rc RenderingContext for this encoding pass
* @param component Component to encode using this Renderer
* @see #tearDownChildrenEncodingContext
*/
public void setupChildrenEncodingContext(
@SuppressWarnings("unused") FacesContext context,
@SuppressWarnings("unused") RenderingContext rc,
@SuppressWarnings("unused") UIComponent component)
/**
* <p>
* Called after rendering the current component's children in order to tear
* down any special context.
* </p>
* <p>
* <code>tearDownChildrenEncodingContext</code> will be called on the
component if
* <code>setupChildrenEncodingContext</code> succeeded.
* </p>
* <p>The default implementation does nothing</p>
* @param context FacesContext for this request
* @param rc RenderingContext for this encoding pass
* @param component Component to encode using this Renderer
* @see #setupChildrenEncodingContext
*/
public void tearDownChildrenEncodingContext(
@SuppressWarnings("unused") FacesContext context,
@SuppressWarnings("unused") RenderingContext rc,
@SuppressWarnings("unused") UIComponent component)
UIXCollection:
/**
* Visit the rows and children of the columns of the collection per row-index.
This should
* not visit row index -1 (it will be perfomed in the visitTree method). The
columns
* themselves should not be visited, only their children in this function.
*
* @param visitContext The visiting context
* @param callback The visit callback
* @return true if the visiting should stop
* @see #visitChildren(VisitContext, VisitCallback)
*/
protected abstract boolean visitData(
VisitContext visitContext,
VisitCallback callback);
> 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: Blake Sullivan
> Fix For: 1.2.13-core
>
> Attachments: JIRA_1368_12101.patch,
> JIRA_1368_More_Traversal_1_2_12_2.patch,
> JIRA_1368_More_Traversal_Trunk.patch, 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.