Hi Robert,
I understand what it is doing now, but still find it non-intuitive. I
think part of this goes back to the whole POJO "subclasses-are-evil"
debate. In my use case, I had an abstract wizard page that had a lot
of concrete subclasses that needed to share data on multiple pages
(@Persist doesn't work in this case, because it persists on the
concrete subclass rather than being shared -- even when defined in the
superclass). In my view of the world, this should all inherit (I'm
old-school). However, even if it is a global session-based variable,
I'd expect it to be isolated by a key (defaulting to the variable
name, perhaps) and not a type so that if you wanted to use different
variable names, you'd have:
Page1.java:
@SessionState(key=Constants.SESSION_OBJECT_CONTEXT)
private ObjectContext context;
Page2.java
@SessionState(key=Constants.SESSION_OBJECT_CONTEXT)
private ObjectContext objectContext;
Leave out the key, and you get two session state variables by
different names. Just my opinion, of course. :-)
Thanks,
mrg
On Thu, Jan 6, 2011 at 11:03 AM, Robert Zeigler
<robert.zeig...@roxanemy.com> wrote:
> Hi Mike,
>
> I understand that the behavior seems a bit non-intuitive. It has to do with
> the fact that the @SessionState objects are global (ie not per-page) objects.
> The decision was made early on to base these solely on the type of the
> object, rather than on the name of the object.
> Usually, @SessionState objects are some unique, application-specific object
> (eg: a "Visit" object for T3/T4 users). I know you're also a cayenne user,
> so imagine:
>
> Page1.java:
> @SessionState
> private ObjectContext context;
>
> Page2.java
> @SessionState
> private ObjectContext objectContext;
>
>
> Assuming you're using the common paradigm of an ObjectContext-per-session,
> wouldn't you expect the context, stored in the session, to be the same in
> these two pages?
>
> @SessionState can be thought of as an easy way to map a page variable to an
> HttpSession-bound variable, based on teh type of the variable. It's a little
> more convoluted than that (or can be), but that sums up the typical use-case.
>
> Robert
>
> On Jan 6, 2011, at 1/69:55 AM , Michael Gentry wrote:
>
>> On Thu, Jan 6, 2011 at 10:14 AM, Thiago H. de Paula Figueiredo
>> <thiag...@gmail.com> wrote:
>>> On Thu, 06 Jan 2011 13:09:43 -0200, Michael Gentry <mgen...@masslight.net>
>>>> Thanks for the explanation, but the types might be a red herring. I'm
>>>> less concerned about that than the fact that Tapestry seems to be
>>>> assigning one of my variables to a different variable. It doesn't
>>>> matter if the types are the same or different. I could've had:
>>>
>>> You're not correct. All @SessionState fields of a given type are mapped to
>>> the same HttpSession attribute, so the behaviour you're experiencing is
>>> exactly the expected, documented one.
>>
>> Hi Thiago,
>>
>> How does this even begin to make sense? If I have:
>>
>> @Property
>> private List<String> list1;
>> @Property
>> private List<String> list2;
>>
>> Are they going to be the same lists, too? (They shouldn't -- I know
>> I've had multiple ValueEncoders in the same page class and they
>> persisted separately). I know I have variables like:
>>
>> private boolean cancelClicked;
>> private boolean saveClicked;
>>
>> Java keeps those two separate. Why would @SessionState operate in an
>> completely different manner? (OK, so maybe it is documented somewhere
>> -- I did look, but didn't find it.)
>>
>> What if you have this?
>>
>> public class Page1
>> {
>> �...@sessionstate(create=false)
>> private List<String> strings;
>> }
>>
>> public class Page2
>> {
>> �...@sessionstate(create=false)
>> private List<String> strings;
>> }
>>
>> Are those two lists in two different pages going to be the same, too?
>> This seems pretty confusing. :-)
>>
>> It seems like I just need a global HashMap somewhere and manage things by
>> key.
>>
>> Thanks again,
>>
>> mrg
>>
>> ---------------------------------------------------------------------
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
