On Thu, 06 Jan 2011 14:42:09 -0200, Donny Nadolny <donny.nado...@gmail.com> wrote:

Hi Nille,

Hi, guys!

I don't think it's the only way to do it. Determining it based on the
variable name (or maybe name/type pair) would work. It would just have a
different set of problems.

Don't forget that @SessionState can't change its implementation details without breaking almost every single application out there. And you always have the option of creating your own annotation and corresponding ComponentClassTransformer.

Also, whoever implements it is going to have to decide how it works when the types are different but compatible. Should List<Object> automatically get assigned if there's a List<String>
there? How about just List?

I think that, in this case, it should be considered different types. Anyway, I'd suggest everyone to create a class to hold this list instead.

With it based on name/type pair, it's clear how it would work in the case
you gave -

This is not an option due to backward compatibility.

Doing it by name essentially creates the equivalent of global variables -
but in a way that makes more sense, because that's what session state is: a global variables in your application.

This could be easily implemented as a different annotation. And yes, I agree the session is a kind of global variable, but user-scoped.

--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
http://www.arsmachina.com.br

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org

Reply via email to