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 Nadolnydonny.nado...@gmail.com
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
mgen...@masslight.netwrote:
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 ListString list1;
@SessionState(create=false)
private ListString 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 time check.
For example, you could do:
ListString strings = new ArrayListString();
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 ArrayListString,
but
it doesn't because at runtime it doesn't do any checks, or even know
that
you put String 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 mgen...@masslight.net
wrote:
Hi everyone,
Given the following page class:
public class Bug
{
@Inject
private Logger log;
@SessionState(create=false)
private ListBoolean booleans;
@SessionState(create=false)
private ListString strings;
void onActivate()
{
log.debug(booleans = + booleans);
log.debug(strings = + strings);
if (booleans == null)
booleans = new ArrayListBoolean();
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
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
-
To unsubscribe,
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 ListObject automatically get assigned if there's a ListString 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 Nadolnydonny.nado...@gmail.com 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 mgen...@masslight.netwrote: 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 ListString list1; @SessionState(create=false) private ListString 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 time check. For example, you could do: ListString strings = new ArrayListString(); 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 ArrayListString, but it doesn't because at runtime it doesn't do any checks, or even know that you put String there (well, there's certain ways of figuring it out, but generally just accept that it doesn't know). All it can do is
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 donny.nado...@gmail.comwrote: 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 ListObject automatically get assigned if there's a ListString 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 Nadolnydonny.nado...@gmail.com 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 mgen...@masslight.netwrote: 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 ListString list1; @SessionState(create=false) private ListString 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 time check. For example, you could do: ListString strings = new ArrayListString(); List strings2 = strings; strings2.add(new Object()); //this line is fine String string = strings.get(0); //throws ClassCastException
Re: Re: @SessionState Bug?
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 ListObject automatically get assigned if there's a ListString 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 donny.nado...@gmail.com 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 ListObject automatically get assigned if there's a ListString 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 Nadolnydonny.nado...@gmail.com 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 mgen...@masslight.netwrote: 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 ListString list1; @SessionState(create=false) private ListString 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 time check. For example, you could do: ListString strings = new ArrayListString(); 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 ArrayListString, but
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 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 ListObject automatically get assigned if there's a ListString 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?
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 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?
On Thu, 06 Jan 2011 14:56:00 -0200, 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... 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 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
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 mgen...@masslight.netwrote: 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
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 mgen...@masslight.netwrote: 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
Re: Re: @SessionState Bug?
On Thu, 06 Jan 2011 17:21:32 -0200, Michael Gentry mgen...@masslight.net 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 CoercionTupleString, User, 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?
Hi Donny, I will always use the name attribute. Thanks, mrg On Thu, Jan 6, 2011 at 2:40 PM, Donny Nadolny donny.nado...@gmail.com 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 mgen...@masslight.netwrote: 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
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 ListShoppingCartItem 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 igor.drobia...@gmail.com 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 mgen...@masslight.netwrote: 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 - 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 thiag...@gmail.com wrote: On Thu, 06 Jan 2011 17:21:32 -0200, Michael Gentry mgen...@masslight.net 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 CoercionTupleString, User, 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! 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 mgen...@masslight.net 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 thiag...@gmail.com wrote: On Thu, 06 Jan 2011 17:21:32 -0200, Michael Gentry mgen...@masslight.net 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 CoercionTupleString, User, 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, 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?
On Thu, Jan 6, 2011 at 9:13 PM, Michael Gentry mgen...@masslight.netwrote: 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?
On Thu, 06 Jan 2011 19:40:31 -0200, Michael Gentry mgen...@masslight.net 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?
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
Re: Re: @SessionState Bug?
On Thu, 06 Jan 2011 21:38:15 -0200, Josh Canfield joshcanfi...@gmail.com 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
