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
