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

Reply via email to