I'm with Igor. :) I've never used @SessionState for "simple" object types
(List, Boolean, String, and the like). I've only ever used it for composite
object types that will only ever have a single object per session ("Visit",
"ShoppingCart", "User", and that ilk). For that matter, in practice, I almost
never use @SessionState. Instead, I usually have a service that interacts
directly with ApplicationStateManager and hides the details (so my pages don't
know anything about the current user, but they do know to ask the Authorization
service whether the current thread/request can perform action xyz). I don't see
myself using @SessionAttribute anytime soon, either, really. For sharing data
across pages, I really do tend to write small services. I find that in the
large majority of cases, shared data also implies some form of shared
functionality (eg: does the user have permission to do xyz?) and the service
model fits better. At least it fits me better. :)
Robert
On Jan 6, 2011, at 1/62:13 PM , Michael Gentry wrote:
> Hi Igor,
>
> How am I missing the use case of doing something like:
>
> @SessionAttribute(value=Constants.USER)
> private User user;
>
> or
>
> @SessionAttribute(value=Constants.SHOPPING_CART)
> private List<ShoppingCartItem> shoppingCartItems;
>
> This does everything that @SessionState does, but gives you more
> control. Plus you can easily use a data type more than once.
>
> Thanks,
>
> mrg
>
>
> On Thu, Jan 6, 2011 at 2:41 PM, Igor Drobiazko <igor.drobia...@gmail.com>
> wrote:
>> Michael,
>>
>> @SessionState will not be deprecated. I guess you are missing the use case
>> for this very useful annotation. Some examples are a logged in user or a
>> shopping basket. Usually you have only one instance of such an object in
>> your app, so it is absolutely fine to same only one instance per app.
>>
>> Regards
>>
>> On Thu, Jan 6, 2011 at 8:21 PM, Michael Gentry <mgen...@masslight.net>wrote:
>>
>>> On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield <joshcanfi...@gmail.com>
>>> wrote:
>>>> In 5.2 there is SessionAttribute which pulls the value from the
>>>> session by name, defaulting to the name of the field...
>>>
>>> Hi Josh,
>>>
>>> @SessionAttribute is working great so far. Thanks again for the tip.
>>>
>>> For discussion by others (if desired):
>>>
>>> I'm going to banish @SessionState from our application soon -- it is
>>> far too dangerous. Imagine you have a large application and you don't
>>> know every single detail on every page/component/mixin/service. The
>>> fact that it it stores things by type instead of a more unique key
>>> means it is quite possible to add an @SessionState somewhere that
>>> conflicts with another somewhere and never know it. You are testing
>>> your little piece of the application and it works fine and it isn't
>>> until some later point (maybe even after deployed) that the
>>> application starts breaking "randomly" as other parts of the code are
>>> used/tested. To give an example of what I mean by a large
>>> application, I just ran this:
>>>
>>> find . -name "*.tml" -print | wc -l
>>> 323
>>>
>>> It is pretty impossible to know what variables (let alone types) are
>>> declared over 300+ Tapestry 5 pages/components. This isn't even
>>> counting mixins or services. I was lucky that my conflict happened to
>>> be in the same page, but it easily could've been in one of the others
>>> and not noticed for some time.
>>>
>>> I'd like to suggest that @SessionState be deprecated in favor of
>>> @SessionAttribute in the future.
>>>
>>> Thoughts?
>>>
>>> Thanks,
>>>
>>> mrg
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>
>>
>> --
>> Best regards,
>>
>> Igor Drobiazko
>> http://tapestry5.de
>>
>
> ---------------------------------------------------------------------
> 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
