Hi Thiago, Absolutely, I agree - @SessionState can't be changed to be based on name. I was just arguing that handling session state based on name is an alternate solution, just they both solutions have a set of problems.
On Thu, Jan 6, 2011 at 11:53 AM, Thiago H. de Paula Figueiredo < thiag...@gmail.com> wrote: > 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 > >
