The RichFaces custom version of PartialViewContext
Important differences of RichFaces implementation:
On following diagram, you can see which classes contributes to RichFaces specific partial view processing (find an explanation bellow):
+-------------------------+ RF: ExtendedPartialViewContextFactory |PartialViewContextFactory| +------------+------------+ +------------------------+ | | PartialViewContext | Mojarra: PartialViewContextImpl +--------------->| | RF: ExtendedPartialViewContext creates |#processPartial(PhaseId)| +--+-------------+-------+ | | RF: ExtendedVisitContextFactory | | +-------------------+ | | |VisitContextFactory| | | +--------------+----+ uses | |creates/uses | | | creates | | | v v v +----------------------------+ +---------------------------+ | VisitContext | | VisitCallback | | | | | | #invokeVisitContext | | #visit | |(UIComponent, VisitCallback)| |(VisitContext, UIComponent)| +----------------------------+ +---------------------------+ Mojarra: PhaseAwareVisitCallback RF: ExtendedExecuteVisitContext RF: MetaComponentProcessingVisitCallback RF: ExtendedRenderVisitContext RF: MetaComponentEncodingVisitCallback +-----------------------------+ | UIViewRoot | | | | #visitTree | |(VisitContext, VisitCallback)| +-----------------------------+
{@link ExtendedPartialViewContext} does (except other things) tracking of the mode ({@link ExtendedVisitContextMode}). This mode determines whether we are not inside a partial processing phase (inside {@link #processPartial(PhaseId)}) or not (determined by mode equal to null).
The knowledge of current mode is leveraged by {@link ExtendedVisitContextFactory} that either use visit context created by parent factory (in a wrapper chain) in case the mode is equal to null or it creates {@link ExtendedExecuteVisitContext} (resp. {@link ExtendedRenderVisitContext}).
(Note: the null mode is necessary because the tree visiting can be leveraged outside of partial tree processing/rendering, e.g. in partial state saving)
These {@link VisitContext} wrappers makes sure that when {@link VisitContext#invokeVisitCallback(UIComponent,VisitCallback)} method is called, the actual {@link VisitCallback} created by JSF implementation is wrapped in wrappers that allows to execute (resp. render) meta-components {@link MetaComponentProcessingVisitCallback} (resp. {@link MetaComponentEncodingVisitCallback}).
While extended {@link VisitContext} implementations ({@link ExtendedRenderVisitContext} and {@link ExtendedExecuteVisitContext}) allows to visit subtrees that are not normally visited (meta-components and implicitly renderer areas, aka {@link AjaxOutput}s),
extended implementations of {@link VisitCallback} ({@link MetaComponentProcessingVisitCallback} and {@link MetaComponentEncodingVisitCallback}) do the extended processing and rendering logic for meta-components.
{@link UIViewRoot} is a place where the tree processing starts to dive into subtrees, it is called by JSF implementation of {@link PartialViewContext#processPartial(PhaseId)}.
This context returns wrapped {@link PartialResponseWriter} in order to intercept its {@link PartialResponseWriter#endDocument()} method and write extensions before the document is actually ended. For more details see {@link ExtensionWritingPartialResponseWriter}. @author Lukas Fryc @author Nick Belaevski
|
|
|
|
|
|
|
|
|
|
|
|