I'm also opposed to deprecating @SessionState, for many of the reasons below.
Perhaps you could build a CYASessionStateWorker that looks at @SessionState annotated fields and pukes if the type is outside of some package you specify. For instance, all of my @SessionState objects generally go in a "state" package as a sibling to pages, components etc. Josh On Thu, Jan 6, 2011 at 11:21 AM, 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
