incubator-adffaces-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Renzo Tomaselli <>
Subject Re: AW: [Trinidad] using t:saveState
Date Wed, 27 Dec 2006 15:19:54 GMT
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<body bgcolor="#ffffff" text="#000000">
<font size="+1">Jochen,<br>
&nbsp;&nbsp;&nbsp; I'm using that snapshot after raising this issue, now saveState
works just fine.<br>
-- Renzo<br>
B&ouml;hringer Jochen wrote:
  <pre wrap="">Hello Adam,

You mentioned that you have fixed the issue. The latest snapshot on
<a class="moz-txt-link-freetext" href=""></a>
ad/trinidad-impl/incubator-m1-SNAPSHOT/ is dated to 20th of december and
your mail is from 21st.

So does this build already contain your fix?


-----Urspr&uuml;ngliche Nachricht-----
Von: Adam Winer [<a class="moz-txt-link-freetext" href=""></a>]

Gesendet: Donnerstag, 21. Dezember 2006 06:57
An: <a class="moz-txt-link-abbreviated" href=""></a>
Betreff: Re: [Trinidad] using t:saveState

YIKES!  Thanks for pointing that glitch out.  *Fixed*.


On 12/20/06, Renzo Tomaselli <a class="moz-txt-link-rfc2396E" href="">&lt;;</a>
  <blockquote type="cite">
    <pre wrap="">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(
            // 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),

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
Indeed the FIXME says all.
-- Renzo

Renzo Tomaselli wrote:
    <blockquote type="cite">
      <pre wrap="">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
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:
      <blockquote type="cite">
        <pre wrap="">Adam,

can you nail that to tomahawks jira?


On 12/20/06, Adam Winer <a class="moz-txt-link-rfc2396E" href="">&lt;;</a>
        <blockquote type="cite">
          <pre wrap="">A magic configuration option should solve the problem



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

View raw message