Hi everybody,
To partially address the concerns raised, and following Pierce's
suggestion (and using many of his words), I have updated this page in
the User Guide to help make it clearer what the pitfalls and decision
points are for using @SessionState and @SessionAttribute:
http://tapestry.apache.org/session-storage.html
Let me know if I didn't capture everything or if anything isn't clear.
On Thu, Jan 6, 2011 at 7:48 PM, Pierce Wetter <pie...@paceap.com> wrote:
>>
>> I'd like to suggest that @SessionState be deprecated in favor of
>> @SessionAttribute in the future.
>>
>> Thoughts?
>
>
> This is ultimately a _documentation_ error. (If we ignore the problem with
> generics for the moment.)
>
> That is, the real problem is that the docs for
> @SessionState/@SessionAttribute really need to discuss the tradeoffs, and the
> documentation for @SessionState should say in big giant bold letters "DO NOT
> USE THIS FOR SIMPLE VARIABLES. BUILD A CUSTOM CLASS OR USE @SessionAttribute."
>
> Similarly, the documentation for @SessionAttribute should say:
>
> "DO NOT USE A SIMPLE NAME. Qualify the name with some sort of package, i.e.
> instead of 'user' use: com.yourcompany.User"
>
> Sample paragraphs to be inserted:
>
> For both of these annotations, you are essentially creating global data that
> will have to be serialized/deserialized/distributed and so on, because its
> stored in the servlet session. As with all global data, there is the
> possibility of collisions, not just with your app but with other Frameworks.
> For that reason, DO NOT USE @SessionState FOR SIMPLE VARIABLES. It is worth
> taking the time to build a class to hold this information, because it will
> force you to consolidate that information into a single, logical unit. Over
> time, you'll be glad you did. That's why @SessionState is the older, and more
> traditional way to do this, because it forces you to build such an object.
>
> That said, there are times when you just want to store a single string, etc.
> In this instance, you can use @SessionAttribute. But you should qualify the
> name with some sort of package, again so you don't have collisions. That is,
> don't use 'username', use 'com.mycompany.username'. DO NOT USE A SIMPLE NAME.
>
> When deciding between the two, it's best to use SessionState for complex
> objects, and SessionAttribute for simple types. If you use SessionState for
> complex objects, you will be immune to any typos in the variable name because
> the compiler will check for you. For SessionAttribute, its best to define a
> constant, and use that rather then defaulting to the instance variable name,
> because otherwise, you could have a subtle runtime error due to a typo.
>
> Pierce
>
>
> Pierce
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
