Great, Adam.
Now boh state restoring and h:commandButton work fine.
Thanks -- Renzo
Adam Winer wrote:
YIKES! Thanks for pointing that glitch out. *Fixed*.
Thanks,
Adam
On 12/20/06, Renzo Tomaselli <[EMAIL PROTECTED]> wrote:
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
>
|
