I'm with Thiago, what you are describing doesn't make sense. It
doesn't matter how you make the request the session stored attributes
should still be there. Since it doesn't make sense I'll ask all the
dumb question:
Are you setting the value somewhere? If you have a setter for it try
setting a breakpoint or add logging...
-- Josh
On May 27, 2010, at 7:32 PM, Paul Stanton <p...@mapshed.com.au> wrote:
Hi Thiago,
please bare with me... I'm not imagining it. I'm guessing it's
something to do with my manually created ajax request...
I'm not inspecting via debugger, I'm testing the value of the field
in code, ie:
via @Persist("session")
if (persistentField == null) LOG.debug("state reset");
and via the @SessionState
if (!persistentFieldExists) LOG.debug("state reset");
please see other email for more info
thanks.
Thiago H. de Paula Figueiredo wrote:
On Thu, 27 May 2010 23:08:37 -0300, Paul Stanton
<p...@mapshed.com.au> wrote:
Hi all,
Hi!
I've noticed that the value for the apparently persistent field is
reset to null when the second type of ajax requests are made ...
this may be because the actions point to different components as
listeners.
How you noticed that? If it was through a debugger, you are looking
at a field which access was replaced by method invocations, so its
value may not be what you expect.
I thought that marking @Persist("session") would mean their values
were stored in the HttpSession until session death or I
specifically set the value to null,
That's exactly what happens. I guess you're misunderstanding
something in your application.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
