THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
...
Any other component or page that declares a field of the same type, regardless of name, and marks it with the SessionState annotation will share the same value. It's that simple. However, using @SessionState safely requires care:
| Warning |
|---|
DO NOT USE THIS FOR SIMPLE TYPES! Only use @SessionState on variables that are of a custom-built class designed expressly for this purpose! Read more below. |
With @SessionState, you are creating session-wide data that is not specifically tied to the variable name you used, or even to the class in which that variable was defined. As with all session data, there is the possibility of collisions, not just within your application but with other modules/libraries.
| Code Block | ||
|---|---|---|
| ||
@SessionState
private String myState; // Unsafe -- String is not a custom type
@sessionState
private String myOtherState; // This overwrites the myState value, because it's also a String!
|
For these reasons, NEVER USE @SessionState FOR SIMPLE-TYPE VARIABLES. It is ALWAYS worth taking the time to build a special class to hold your session state information, because it will force you to consolidate that information into a single, logical unit that can't be accidentally accessed by other classes.
For Tapestry 4 Users: a big change here is that you don't need to provide any configuration for the SSO before using it, nor do you provide a logical name. Tapestry 5 uses the class name to identify the SSO, so there's no need for a logical name.
...