Re: Re: @SessionState Bug?
On Thu, 06 Jan 2011 21:38:15 -0200, Josh Canfield wrote: 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. This gave me an idea: we could create a very pedantic mode or separate package that checks for things that are valid but not recommended (such as using @SessionState with String fields or initializing component fields with known mutable objects) and throws an exception if some offending code is found. This could include Josh's idea of checking for @SessionState fields which types are outside some configurable safe package (.sessionstate?). A little bit like a FindBugs for Tapestry. What do you think? :) -- 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
Re: Re: @SessionState Bug?
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 wrote: > On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield 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
Re: Re: @SessionState Bug?
On Thu, 06 Jan 2011 19:40:31 -0200, Michael Gentry wrote: Hi Thiago, Hi, Michael! I meant to mention that I don't consider "@SessionState has been used as it is since Tapetry 5 exists." to be a very good reason/excuse because @IncludeJavaScriptLibrary and @IncludeStylesheet are now deprecated. I don't think this is the same situation, as internally there have been some internal changes to the JavaScript support, including the JS stacks. My argument was that you're maybe the first to complain/dislike the @SessionState behaviour since Tapestry 5 was created. Most people, including the Tapestry team, are happy with @SessionState as it is implemented. Things sometimes change (and hopefully for the better). :-) Things do sometimes change, but this is a very sensitive issue for Tapestry. Great food for trolls (not you, of course). Some trolls still complain that T5 isn't compatible at all with T4, even after three years of T5 with minimum non-backward compatible changes. -- 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
Re: Re: @SessionState Bug?
On Thu, Jan 6, 2011 at 9:13 PM, Michael Gentry wrote: > Hi Igor, > > This does everything that @SessionState does, but gives you more > control. Plus you can easily use a data type more than once. > > > Nope, with @SessionState you have auto-building of SSOs and co-called accompany-fields to check the existence of the SSO. You have ApplicationStateManager which gives you the power over your SSOs. And you don't have to repeat yourself as you don't have to provide the session key every time you use the annotation. In fact, you don't even need the session for SSOs as you can change the persistent strategy. Furthermore, if your SSO is a Hibernate entity only its primary key is persisted into the session, not the entire object. This ensures a lean HTTP session usage. All this is not possible with @SessionAttribute. Convinced? -- Best regards, Igor Drobiazko http://tapestry5.de
Re: Re: @SessionState Bug?
Hi Thiago, I meant to mention that I don't consider "@SessionState has been used as it is since Tapetry 5 exists." to be a very good reason/excuse because @IncludeJavaScriptLibrary and @IncludeStylesheet are now deprecated. Things sometimes change (and hopefully for the better). :-) Cheers, mrg - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Re: @SessionState Bug?
Hi!
As I said, in this case, what you consider dangerous I consider safe and
vice-versa. Just different opinions. :) I agree that there's no completely
safe option. Both have their pros and cons. And I don't consider
@SessionState data-dangerous at all. I'd never use non-specific object
types with it, though, such as collections, string or numbers, just
classes belonging to the project being developed.
On Thu, 06 Jan 2011 18:24:25 -0200, Michael Gentry
wrote:
Hi Thiago,
You argue that @SessionState is type-safe, but it is data-dangerous.
Is that a good trade-off? I personally want my data to be safe, too.
:-)
Also, If I do:
@SessionAttribute("user")
private String user;
On something that was already set to be a User record (instead of a
string), it'll blow up immediately with a class cast exception. (Or
vice-versa.) That at least seems safer to me. Ideally I'd prefer
something more safe, but that doesn't seem to be an option, currently.
Also, I'm planning on using more verbose keys than "user". That's
just a convention, though, and not a guarantee of safety.
Thanks!
mrg
On Thu, Jan 6, 2011 at 2:45 PM, Thiago H. de Paula Figueiredo
wrote:
On Thu, 06 Jan 2011 17:21:32 -0200, Michael Gentry
wrote:
I'd like to suggest that @SessionState be deprecated in favor of
@SessionAttribute in the future.
I'm completely against. @SessionState has been used as it is since
Tapetry 5
exists. I think @SessionAttribute is dangerous for almost the same
arguments
you use against @SessionState. One thing that I loved in Tapestry,
coming
from a Struts (argh!) background, was that @SessionState avoids the
problem
of having different parts of the code ending up using the same session
attribute name for very different things (including storing different
object
types). @SessionState is type-safe, @SessionAttribute isn't (if one page
stores a string in the "user" session attribute and then another one
has a
@SessionAttribute("user") private User user; field, unless you provided
a
CoercionTuple, it will probably fail).
Conclusion: what is a heaven for one can be a hell for another. :)
--
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
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
Thiago H. de Paula Figueiredo
Independent Java, Apache Tapestry 5 and Hibernate consultant, developer,
and instructor
Owner, Ars Machina Tecnologia da Informação Ltda.
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Coordenador e professor da Especialização em Engenharia de Software com
Ênfase em Java da Faculdade Pitágoras
http://www.arsmachina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Re: @SessionState Bug?
Hi Thiago,
You argue that @SessionState is type-safe, but it is data-dangerous.
Is that a good trade-off? I personally want my data to be safe, too.
:-)
Also, If I do:
@SessionAttribute("user")
private String user;
On something that was already set to be a User record (instead of a
string), it'll blow up immediately with a class cast exception. (Or
vice-versa.) That at least seems safer to me. Ideally I'd prefer
something more safe, but that doesn't seem to be an option, currently.
Also, I'm planning on using more verbose keys than "user". That's
just a convention, though, and not a guarantee of safety.
Thanks!
mrg
On Thu, Jan 6, 2011 at 2:45 PM, Thiago H. de Paula Figueiredo
wrote:
> On Thu, 06 Jan 2011 17:21:32 -0200, Michael Gentry
> wrote:
>
>> I'd like to suggest that @SessionState be deprecated in favor of
>> @SessionAttribute in the future.
>
> I'm completely against. @SessionState has been used as it is since Tapetry 5
> exists. I think @SessionAttribute is dangerous for almost the same arguments
> you use against @SessionState. One thing that I loved in Tapestry, coming
> from a Struts (argh!) background, was that @SessionState avoids the problem
> of having different parts of the code ending up using the same session
> attribute name for very different things (including storing different object
> types). @SessionState is type-safe, @SessionAttribute isn't (if one page
> stores a string in the "user" session attribute and then another one has a
> @SessionAttribute("user") private User user; field, unless you provided a
> CoercionTuple, it will probably fail).
>
> Conclusion: what is a heaven for one can be a hell for another. :)
>
> --
> 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
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Re: @SessionState Bug?
Hi Igor, How am I missing the use case of doing something like: @SessionAttribute(value=Constants.USER) private User user; or @SessionAttribute(value=Constants.SHOPPING_CART) private List shoppingCartItems; This does everything that @SessionState does, but gives you more control. Plus you can easily use a data type more than once. Thanks, mrg On Thu, Jan 6, 2011 at 2:41 PM, Igor Drobiazko wrote: > 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 wrote: > >> On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield >> 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 > - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Re: @SessionState Bug?
Hi Donny, I will always use the name attribute. Thanks, mrg On Thu, Jan 6, 2011 at 2:40 PM, Donny Nadolny 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 wrote: > >> On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield >> 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
Re: Re: @SessionState Bug?
On Thu, 06 Jan 2011 17:21:32 -0200, Michael Gentry
wrote:
I'd like to suggest that @SessionState be deprecated in favor of
@SessionAttribute in the future.
I'm completely against. @SessionState has been used as it is since Tapetry
5 exists. I think @SessionAttribute is dangerous for almost the same
arguments you use against @SessionState. One thing that I loved in
Tapestry, coming from a Struts (argh!) background, was that @SessionState
avoids the problem of having different parts of the code ending up using
the same session attribute name for very different things (including
storing different object types). @SessionState is type-safe,
@SessionAttribute isn't (if one page stores a string in the "user" session
attribute and then another one has a @SessionAttribute("user") private
User user; field, unless you provided a CoercionTuple, it
will probably fail).
Conclusion: what is a heaven for one can be a hell for another. :)
--
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
Re: Re: @SessionState Bug?
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 wrote: > On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield > 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
Re: Re: @SessionState Bug?
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 wrote: > On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield > 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 > >
Re: Re: @SessionState Bug?
On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield 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
Re: Re: @SessionState Bug?
On Thu, 06 Jan 2011 14:56:00 -0200, Josh Canfield wrote: In 5.2 there is SessionAttribute which pulls the value from the session by name, defaulting to the name of the field... Ooops, I missed that. Thanks Josh! -- 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
Re: Re: @SessionState Bug?
On Thu, Jan 6, 2011 at 11:56 AM, Josh Canfield 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 sounds much more promising to me. Thanks for the tip! mrg - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Re: @SessionState Bug?
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 > 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 automatically >> get assigned if there's a List >> 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 > >
Re: Re: @SessionState Bug?
In 5.2 there is SessionAttribute which pulls the value from the session by name, defaulting to the name of the field... On Thu, Jan 6, 2011 at 8:42 AM, Donny Nadolny wrote: > Hi Nille, > > 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. > > Based on types, the problems are that you get unintuitive results, > especially with generics - it's not clear just from a brief description of > the feature, eg "values are assigned based on the type", which way it will > behave (are types with different generic arguments different or the same? > right now they're considered the same type, but it was mentioned earlier in > this thread that it's going to change). Also, whoever implements it is going > to have to decide how it works when the types are different but compatible. > Should List automatically get assigned if there's a List > there? How about just List? > > With it based on name/type pair, it's clear how it would work in the case > you gave - they would be different values because even though they have the > same name (ignoring case), they have different types. The disadvantage is > with refactoring, and being forced to use the same name if you want to get > the same object (although I don't think that's too much of a downside, > especially if you could give an override name, like it's done with > @InjectComponent - by default it uses the variable name to link it, but you > can pass a name if you want to name them differently). > > 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. > > > On Thu, Jan 6, 2011 at 10:56 AM, nille hammer < > tapestry.nilleham...@winfonet.eu> wrote: > >> Hi Donny, >> >> If you think a bit further, assigning the value based on the type is the >> only sensible way to do it. If the value was assigned based on the variable >> name, you would have to use that exact variable name in every component and >> page you want to use your SessionState-Object. That is extremely intrusive >> and surely not easy to maintain. And even if you were able to maintain that. >> What would you expect Tapestry to do in the following case? >> Component1 >> @SessionState >> private String eMailAddress; >> >> Component2 >> @SessionState >> private EmailAddress emailAddress; >> >> regards nillehammer >> >> - original Nachricht >> >> Betreff: Re: @SessionState Bug? >> Gesendet: Do, 06. Jan 2011 >> Von: Donny Nadolny >> >> > Ah that's the problem then. You're expecting them to be assigned based on >> > the name of the variable, but @SessionState assigns them based on their >> > type. >> > >> > You could have in page1: >> > @SessionState >> > private String username; >> > >> > In page 2: >> > @SessionState >> > private String email; >> > >> > And they would be assigned to the same thing, because it's done based on >> > the >> > type rather than the variable name. >> > >> > I see how this would be confusing though - it does seem intuitive that >> they >> > would be assigned based on the variable name. >> > >> > On Thu, Jan 6, 2011 at 10:09 AM, Michael Gentry >> > wrote: >> > >> > > Hi Donny, >> > > >> > > Thanks for the explanation, but the types might be a red herring. I'm >> > > less concerned about that than the fact that Tapestry seems to be >> > > assigning one of my variables to a different variable. It doesn't >> > > matter if the types are the same or different. I could've had: >> > > >> > > @SessionState(create=false) >> > > private List list1; >> > > @SessionState(create=false) >> > > private List list2; >> > > >> > > And I'd still expect to have two separate/distinct variables and >> > > lists, not two variables pointing to the same list (unless I >> > > specifically assigned them to the same list myself). >> > > >> > > Thanks, >> > > >> > > mrg >> > > >> > > >> > > On Thu, Jan 6, 2011 at 9:57 AM, Donny Nadolny > > >> > > wrote: >> > > > Your two lists are the same - they're both of type List so they both >> > get >> > > > assigned to the same thing. See below for why. >> > > > >> > > > The solution is to make two classes, one that holds the booleans, and >> > one >> > > > that holds the strings. Technically you would only need to do that >> for >> > > one, >> > > > but it's probably a good idea to do it for both anyway. >> > > > >> > > > The reason why they're both considered the same: this has to do with >> > how >> > > > generics work in Java. It's called type erasure - after the class is >> > > > compiled, the generic type is erased, so at runtime it doesn't care >> > what >> > > the >> > > > type is. Generics are a compile time check. >> > > > >> > > > For example, you could do: >> > > > List strings = new ArrayList(); >> > > > List strings2 = strings; >> > > > strings2.add(new Object()); //this line is fine >> > > > Str
Re: Re: @SessionState Bug?
On Thu, 06 Jan 2011 14:42:09 -0200, Donny Nadolny 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 automatically get assigned if there's a List 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
Re: Re: @SessionState Bug?
One other point - part of the downside of the current way could be avoided with error messages. You should probably get a warning if you have two @SessionState variables in your page that map to the same session variable, because it's unlikely that's what you actually intended to do. On Thu, Jan 6, 2011 at 11:42 AM, Donny Nadolny wrote: > Hi Nille, > > 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. > > Based on types, the problems are that you get unintuitive results, > especially with generics - it's not clear just from a brief description of > the feature, eg "values are assigned based on the type", which way it will > behave (are types with different generic arguments different or the same? > right now they're considered the same type, but it was mentioned earlier in > this thread that it's going to change). Also, whoever implements it is going > to have to decide how it works when the types are different but compatible. > Should List automatically get assigned if there's a List > there? How about just List? > > With it based on name/type pair, it's clear how it would work in the case > you gave - they would be different values because even though they have the > same name (ignoring case), they have different types. The disadvantage is > with refactoring, and being forced to use the same name if you want to get > the same object (although I don't think that's too much of a downside, > especially if you could give an override name, like it's done with > @InjectComponent - by default it uses the variable name to link it, but you > can pass a name if you want to name them differently). > > 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. > > > > On Thu, Jan 6, 2011 at 10:56 AM, nille hammer < > tapestry.nilleham...@winfonet.eu> wrote: > >> Hi Donny, >> >> If you think a bit further, assigning the value based on the type is the >> only sensible way to do it. If the value was assigned based on the variable >> name, you would have to use that exact variable name in every component and >> page you want to use your SessionState-Object. That is extremely intrusive >> and surely not easy to maintain. And even if you were able to maintain that. >> What would you expect Tapestry to do in the following case? >> Component1 >> @SessionState >> private String eMailAddress; >> >> Component2 >> @SessionState >> private EmailAddress emailAddress; >> >> regards nillehammer >> >> - original Nachricht >> >> Betreff: Re: @SessionState Bug? >> Gesendet: Do, 06. Jan 2011 >> Von: Donny Nadolny >> >> > Ah that's the problem then. You're expecting them to be assigned based >> on >> > the name of the variable, but @SessionState assigns them based on their >> > type. >> > >> > You could have in page1: >> > @SessionState >> > private String username; >> > >> > In page 2: >> > @SessionState >> > private String email; >> > >> > And they would be assigned to the same thing, because it's done based on >> > the >> > type rather than the variable name. >> > >> > I see how this would be confusing though - it does seem intuitive that >> they >> > would be assigned based on the variable name. >> > >> > On Thu, Jan 6, 2011 at 10:09 AM, Michael Gentry >> > wrote: >> > >> > > Hi Donny, >> > > >> > > Thanks for the explanation, but the types might be a red herring. I'm >> > > less concerned about that than the fact that Tapestry seems to be >> > > assigning one of my variables to a different variable. It doesn't >> > > matter if the types are the same or different. I could've had: >> > > >> > > @SessionState(create=false) >> > > private List list1; >> > > @SessionState(create=false) >> > > private List list2; >> > > >> > > And I'd still expect to have two separate/distinct variables and >> > > lists, not two variables pointing to the same list (unless I >> > > specifically assigned them to the same list myself). >> > > >> > > Thanks, >> > > >> > > mrg >> > > >> > > >> > > On Thu, Jan 6, 2011 at 9:57 AM, Donny Nadolny < >> donny.nado...@gmail.com> >> > > wrote: >> > > > Your two lists are the same - they're both of type List so they both >> > get >> > > > assigned to the same thing. See below for why. >> > > > >> > > > The solution is to make two classes, one that holds the booleans, >> and >> > one >> > > > that holds the strings. Technically you would only need to do that >> for >> > > one, >> > > > but it's probably a good idea to do it for both anyway. >> > > > >> > > > The reason why they're both considered the same: this has to do with >> > how >> > > > generics work in Java. It's called type erasure - after the class is >> > > > compiled, the generic type is erased, so at runtime it doesn't care >> > what >> > > the >> > > > type is. Generics are a compile
Re: Re: @SessionState Bug?
Hi Nille, 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. Based on types, the problems are that you get unintuitive results, especially with generics - it's not clear just from a brief description of the feature, eg "values are assigned based on the type", which way it will behave (are types with different generic arguments different or the same? right now they're considered the same type, but it was mentioned earlier in this thread that it's going to change). Also, whoever implements it is going to have to decide how it works when the types are different but compatible. Should List automatically get assigned if there's a List there? How about just List? With it based on name/type pair, it's clear how it would work in the case you gave - they would be different values because even though they have the same name (ignoring case), they have different types. The disadvantage is with refactoring, and being forced to use the same name if you want to get the same object (although I don't think that's too much of a downside, especially if you could give an override name, like it's done with @InjectComponent - by default it uses the variable name to link it, but you can pass a name if you want to name them differently). 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. On Thu, Jan 6, 2011 at 10:56 AM, nille hammer < tapestry.nilleham...@winfonet.eu> wrote: > Hi Donny, > > If you think a bit further, assigning the value based on the type is the > only sensible way to do it. If the value was assigned based on the variable > name, you would have to use that exact variable name in every component and > page you want to use your SessionState-Object. That is extremely intrusive > and surely not easy to maintain. And even if you were able to maintain that. > What would you expect Tapestry to do in the following case? > Component1 > @SessionState > private String eMailAddress; > > Component2 > @SessionState > private EmailAddress emailAddress; > > regards nillehammer > > - original Nachricht > > Betreff: Re: @SessionState Bug? > Gesendet: Do, 06. Jan 2011 > Von: Donny Nadolny > > > Ah that's the problem then. You're expecting them to be assigned based on > > the name of the variable, but @SessionState assigns them based on their > > type. > > > > You could have in page1: > > @SessionState > > private String username; > > > > In page 2: > > @SessionState > > private String email; > > > > And they would be assigned to the same thing, because it's done based on > > the > > type rather than the variable name. > > > > I see how this would be confusing though - it does seem intuitive that > they > > would be assigned based on the variable name. > > > > On Thu, Jan 6, 2011 at 10:09 AM, Michael Gentry > > wrote: > > > > > Hi Donny, > > > > > > Thanks for the explanation, but the types might be a red herring. I'm > > > less concerned about that than the fact that Tapestry seems to be > > > assigning one of my variables to a different variable. It doesn't > > > matter if the types are the same or different. I could've had: > > > > > > @SessionState(create=false) > > > private List list1; > > > @SessionState(create=false) > > > private List list2; > > > > > > And I'd still expect to have two separate/distinct variables and > > > lists, not two variables pointing to the same list (unless I > > > specifically assigned them to the same list myself). > > > > > > Thanks, > > > > > > mrg > > > > > > > > > On Thu, Jan 6, 2011 at 9:57 AM, Donny Nadolny > > > > wrote: > > > > Your two lists are the same - they're both of type List so they both > > get > > > > assigned to the same thing. See below for why. > > > > > > > > The solution is to make two classes, one that holds the booleans, and > > one > > > > that holds the strings. Technically you would only need to do that > for > > > one, > > > > but it's probably a good idea to do it for both anyway. > > > > > > > > The reason why they're both considered the same: this has to do with > > how > > > > generics work in Java. It's called type erasure - after the class is > > > > compiled, the generic type is erased, so at runtime it doesn't care > > what > > > the > > > > type is. Generics are a compile time check. > > > > > > > > For example, you could do: > > > > List strings = new ArrayList(); > > > > List strings2 = strings; > > > > strings2.add(new Object()); //this line is fine > > > > String string = strings.get(0); //throws ClassCastException > > > > > > > > You might think that the strings2.add(new Object()) would have a > > problem > > > > because strings2 is pointing to strings which is an > ArrayList, > > > but > > > > it doesn't because at runtime it doesn't do any checks, or even know > > that > > > > yo
Re: Re: @SessionState Bug?
Hi Donny,
If you think a bit further, assigning the value based on the type is the only
sensible way to do it. If the value was assigned based on the variable name,
you would have to use that exact variable name in every component and page you
want to use your SessionState-Object. That is extremely intrusive and surely
not easy to maintain. And even if you were able to maintain that. What would
you expect Tapestry to do in the following case?
Component1
@SessionState
private String eMailAddress;
Component2
@SessionState
private EmailAddress emailAddress;
regards nillehammer
- original Nachricht
Betreff: Re: @SessionState Bug?
Gesendet: Do, 06. Jan 2011
Von: Donny Nadolny
> Ah that's the problem then. You're expecting them to be assigned based on
> the name of the variable, but @SessionState assigns them based on their
> type.
>
> You could have in page1:
> @SessionState
> private String username;
>
> In page 2:
> @SessionState
> private String email;
>
> And they would be assigned to the same thing, because it's done based on
> the
> type rather than the variable name.
>
> I see how this would be confusing though - it does seem intuitive that they
> would be assigned based on the variable name.
>
> On Thu, Jan 6, 2011 at 10:09 AM, Michael Gentry
> wrote:
>
> > Hi Donny,
> >
> > Thanks for the explanation, but the types might be a red herring. I'm
> > less concerned about that than the fact that Tapestry seems to be
> > assigning one of my variables to a different variable. It doesn't
> > matter if the types are the same or different. I could've had:
> >
> > @SessionState(create=false)
> > private List list1;
> > @SessionState(create=false)
> > private List list2;
> >
> > And I'd still expect to have two separate/distinct variables and
> > lists, not two variables pointing to the same list (unless I
> > specifically assigned them to the same list myself).
> >
> > Thanks,
> >
> > mrg
> >
> >
> > On Thu, Jan 6, 2011 at 9:57 AM, Donny Nadolny
> > wrote:
> > > Your two lists are the same - they're both of type List so they both
> get
> > > assigned to the same thing. See below for why.
> > >
> > > The solution is to make two classes, one that holds the booleans, and
> one
> > > that holds the strings. Technically you would only need to do that for
> > one,
> > > but it's probably a good idea to do it for both anyway.
> > >
> > > The reason why they're both considered the same: this has to do with
> how
> > > generics work in Java. It's called type erasure - after the class is
> > > compiled, the generic type is erased, so at runtime it doesn't care
> what
> > the
> > > type is. Generics are a compile time check.
> > >
> > > For example, you could do:
> > > List strings = new ArrayList();
> > > List strings2 = strings;
> > > strings2.add(new Object()); //this line is fine
> > > String string = strings.get(0); //throws ClassCastException
> > >
> > > You might think that the strings2.add(new Object()) would have a
> problem
> > > because strings2 is pointing to strings which is an ArrayList,
> > but
> > > it doesn't because at runtime it doesn't do any checks, or even know
> that
> > > you put there (well, there's certain ways of figuring it out,
> > but
> > > generally just accept that it doesn't know). All it can do is give a
> > warning
> > > at "List strings2 = strings" because you're doing some potentially type
> > > unsafe things.
> > >
> > >
> > > On Thu, Jan 6, 2011 at 9:38 AM, Michael Gentry > >wrote:
> > >
> > >> Hi everyone,
> > >>
> > >> Given the following page class:
> > >>
> > >>
> > >> public class Bug
> > >> {
> > >>@Inject
> > >>private Logger log;
> > >>
> > >>@SessionState(create=false)
> > >>private List booleans;
> > >>
> > >>@SessionState(create=false)
> > >>private List strings;
> > >>
> > >>void onActivate()
> > >>{
> > >>log.debug("booleans = " + booleans);
> > >>log.debug("strings = " + strings);
> > >>
> > >>if (booleans == null)
> > >>booleans = new ArrayList();
> > >>
> > >>booleans.add(Boolean.TRUE);
> > >>
> > >>log.debug("booleans: " + booleans);
> > >>log.debug("strings: " + strings);
> > >>log.debug("equal? " + booleans.equals(strings));
> > >>}
> > >> }
> > >>
> > >> I get this output:
> > >>
> > >> DEBUG 2011-01-06 09:35:24,014 booleans = null
> > >> DEBUG 2011-01-06 09:35:24,014 strings = null
> > >> DEBUG 2011-01-06 09:35:24,014 booleans: [true]
> > >> DEBUG 2011-01-06 09:35:24,014 strings: [true]
> > >> DEBUG 2011-01-06 09:35:24,015 equal? true
> > >>
> > >>
> > >> Even though I don't add anything to the strings list or even allocate
> > >> the strings list, it seems to be pointing to the booleans list, which
> > >> is, of course, incorrect. This seems to be happening on both 5.1 and
> > >> 5.2. Am I missing something?
> > >>
> > >> Thanks,
> > >>
> > >> mrg
> > >>
> > >>
