After some debugging, I noticed that the suggested parameter cannot
work, since we have (in StateManagerImpl.saveSerializedView()):
// FIXME: pageState is never read
PageState pageState = new PageState(
context,
structure,
state,
// Save the view root into the page state as a transient
// if this feature has not been disabled
_useViewRootCache(context) ? root : null);
token = cache.addNewEntry(new PageState(context, structure,
state, root),
stateMap);
thus a valid root to cache is always passed in to PageState constructor,
no matter the value of useViewRootCache, which is set according to the
parameter.
Indeed the FIXME says all.
-- Renzo
Renzo Tomaselli wrote:
Matthias, I placed the param below at the beginning of web.xml, but
things run as before, e.g. viewState.popRoot(context) gets called
while restoring every view.
I could not spot where this caching optimization should depend on a
parameter.
Where can I control that flag from sources and how can I turn Trinidad
logging to a finer grain ?
Btw, I noticed another misbehavior which might be related to wrong
view caching. I have a page with a section which is rendered according
to a show/hide button.
It happens sometime that - with details hidden - bean setters are
called for actually unrendered components, much like having a
mismatch between actual view and the cache. New value passed in is
null though, hence quite a number of troubles.
-- Renzo
Matthias Wessendorf wrote:
Adam,
can you nail that to tomahawks jira?
thx,
On 12/20/06, Adam Winer <[EMAIL PROTECTED]> wrote:
A magic configuration option should solve the problem
<context-param>
<param-name>org.apache.myfaces.trinidad.CACHE_VIEW_ROOT</param-name>
<param-value>false</param-value>
</context-param>
The optimization in StateManagerImpl is very significant, but it
*does* break t:saveState - since when it is in effect, we can skip
processRestoreState() altogether. It'd be a Good Thing if t:saveState
was able to deal with StateManagers that include this optimization.
-- Adam
