Hi Donny, I will always use the name attribute.
Thanks, mrg On Thu, Jan 6, 2011 at 2:40 PM, Donny Nadolny <donny.nado...@gmail.com> wrote: > 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 >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
