You could still have the problem of someone using @SessionAttribute and giving the variable the same name as some other session variable.
I might take it one step further - declare a single class/enum with the names of all of your session variables, and *always* use the name parameter for @SessionAttribute. With this way, you can easily check who else is using the same session variable. It's ugly to have all these names that are for different pages/components all in one class, but it just mirrors the fact that you have global variables. Now that I think about it, there are potential conflicts with component libraries. A component could declare a @SessionAttribute with a certain name, and you just happen to use the same name in your application (or worse - a component library uses the same name as another component library). Maybe SessionAttribute names should be scoped by default somehow, by library/project name? In such a way that you could still access a different "namespace"'s session variables if necessary. Or, a backwards compatible solution is just to make it common practice for session variable names to be prefixed with the project/library name to prevent these conflicts. On Thu, Jan 6, 2011 at 2: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 > >
