StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>As with any performance problem, a profiler would help greatly in locating the bottlenecks. (Yes, you know it is the restore_view phase, but not where in the restore_view phase).</p> <p>That said, the restore view phase indeed restores the entire view, not just the parts that will be processed or rendered. Quoting the <a href="http://docs.jboss.org/richfaces/latest_3_3_X/en/tlddoc/a4j/support.html" rel="noreferrer">RichFaces taglib documentation</a>:</p> <blockquote> <p>process: Id['s] (in format of call UIComponent.findComponent()) of components, processed at the phases 2-5 in case of AjaxRequest caused by this component. Can be single id, comma-separated list of Id's, or EL Expression with array or Collection</p> </blockquote> <p>RESTORE_VIEW is phase 1. Also:</p> <blockquote> <p>reRender: Id['s] (in format of call UIComponent.findComponent()) of components, rendered in case of AjaxRequest caused by this component. Can be single id, comma-separated list of Id's, or EL Expression with array or Collection</p> </blockquote> <p>Moreover, I am not sure that UIComponent.findComponent() is implemented using a more suitable datastructure than a component tree. (Finding something in the component tree would boil down to linear search ...).</p> <p>I have observed similar effects with JSF 2.0 (Mojarra). My conclusion was that views must not contain more than a couple dozen UIComponents, irrespective of whether they are rendered. (Put differently, AJAX is unsuitable for page navigation.) We indend to keep views small by including only components that are currently visible in the view, and switch views if many new components need to appear. That is, instead of one view with 10 tabs with 30 components each, we'd have 10 views, each only containing the content of a single tab. A drawback of that approach is that components are disposed when switching tabs, causing any state not held in backing beans to be lost.</p> <p>I do not claim this to be a good solution. Alas, it was the best one I found when looking into this a couple weeks ago. I'd be happy to be shown a better one, too.</p> <p><strong>Edit</strong> When I say restore, I mean <code>ViewHandler.restoreView()</code>, which called both for an initial get request and a postback. It is incorrect to say that <code>restoreView</code> would simply reuse an existing view as is. For instance, the JSF 2.0 spec mandates in section 7.6.2.7: ]</p> <blockquote> <p>The <code>restoreView()</code> method must fulfill the following responsibilities:</p> <p>All implementations must:</p> <ul> <li>If no viewId could be identified, return <code>null</code>.</li> <li>Call the <code>restoreView()</code> method of the associated <code>StateManager</code> , passing the <code>FacesContext</code> instance for the current request and the calculated viewId, and return the returned <code>UIViewRoot</code>, which may be <code>null</code>.</li> </ul> </blockquote> <p>and in section 7.7.2:</p> <blockquote> <p>JSF implementations support two primary mechanisms for saving state, based on the value of the javax.faces.STATE_SAVING_METHOD initialization parameter (see Section 11.1.3 “Application Configuration Parameters”). The possible values for this parameter give a general indication of the approach to be used, while allowing JSF implementations to innovate on the technical details:</p> <ul> <li>client -- [...]</li> <li>server -- Cause the saved state to be stored on the server in between requests. Implementations that wish to enable their saved state to fail over to a different container instance must keep this in mind when implementing their server side state saving strategy. The default implementation Serializes the view in both the client and server modes. In the server mode, this serialized view is stored in the session and a unique key to retrieve the view is sent down to the client. By storing the serialized view in the session, failover may happen using the usual mechanisms provided by the container.</li> </ul> </blockquote> <p>Put differently, the AJAX support added to JSF (both the one added by RichFaces 3 to JSF 1.2, and the one incorporated into JSF 2.0) aims to reduce network bandwith consumption, not server side cpu consumption. </p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload