GPMSWiki/DeveloperDocumentation/MigrationHelp/SessionManagementChanges: Difference between revisions
imported>MichaelDondrup No edit summary |
imported>MichaelDondrup No edit summary |
||
Line 31: | Line 31: | ||
use base qw(Session::GPMS::Application); | use base qw(Session::GPMS::Application); | ||
1; | 1; | ||
Line 53: | Line 54: | ||
</nowiki></pre> | </nowiki></pre> | ||
== Initialization of Sessions == | |||
With the new session management there are normally al least two session: | |||
* Session::Master -- the root session from which others can be derived | |||
* Session::GPMS::<[[YourApp]]> -- an application-specific session, sublclass of Session::GPMS as given above | |||
The session management supports multiple sessions of the same type, if your application does not: use singleton session. currently most of our apps | |||
only support a single instance. | |||
To retrieve valid sessions for your application the following steps have to be performed: | |||
# No Session at all -> check if browser accepts cookies | |||
# Check if you can resume Session::Master, if not: new Session::Master. The master session already sets the cookie. | |||
# Check if you are having an authenticated session, that is have already given login/passw | |||
# If not: get credentials and | |||
# authenticate, getting a Session::GPMS::<[[YourApp]]> | |||
# Set the project for this session | |||
once you have and authenticated Session::GPMS::<[[YourApp]]> the session can be resumed using <code><nowiki>Session::GPMS::<[[YourApp]]>->loadSingleton($masterSession);</nowiki></code> if it is a singleton session. | |||
== API == | == API == | ||
The API is completely different from the old one, especially when it come to initialization of sessions. The only function that is unchanged is '''param''', fortunately ;-) It can be used to get and set session parameters | The API is completely different from the old one, especially when it come to initialization of sessions. The only function that is unchanged is '''param''', fortunately ;-) It can be used to get and set session parameters. | ||
* The function '''params''' delivered all parameter values as key value pairs. This function does no longer exist. To replace it: | * The function '''params''' delivered all parameter values as key value pairs. This function does no longer exist. To replace it: | ||
Line 62: | Line 83: | ||
** use ''param'' on each name and store the value | ** use ''param'' on each name and store the value | ||
* There is no '''param_permanent''' any more, because you don't want it :-| If you do, blame Burkhard and suffer | * There is no '''param_permanent''' any more, because you don't want it :-| If you do, blame Burkhard and suffer | ||
* the function '''delete_param''' removes the param value, which was before done by setting the param to undef |
Revision as of 11:35, 7 November 2008
Changes in the Session Management
The new Sessionmanagement module is completely new and build from scratch. It supports hierarchical sessions, and also anonymous sessions. Complete redesign implies vast changes throughout the API. So expect some work.
Classes
You can have multiple sessions of different classes. An application specific subclass of Session::GPMS is mandatory. It has to be placed in the application subdirectory share/perl/Session/GPMS.
Here is a simple example:
package Session::GPMS::EMMAII; =head1 NAME Session::GPMS::EMMA2 =head1 DESCRIPTION Sample implementation of a Session::GPMS::Application class, using GPMS::Application_Frame::Sample =cut use strict; use warnings; use GPMS::Application_Frame::EMMAII; use base qw(Session::GPMS::Application); 1; ### Begin Class Methods ### sub AppFrameClass { # we use GPMS::Application_Frame::EMMAII return "GPMS::Application_Frame::EMMAII"; } sub NeedSingleton { # we cannot have multiple instances of an EMMA apllications at the moment # this could change in the future.... return 1; } ### End Class Methods ### __END__
Initialization of Sessions
With the new session management there are normally al least two session:
- Session::Master -- the root session from which others can be derived
- Session::GPMS::<YourApp> -- an application-specific session, sublclass of Session::GPMS as given above
The session management supports multiple sessions of the same type, if your application does not: use singleton session. currently most of our apps only support a single instance.
To retrieve valid sessions for your application the following steps have to be performed:
- No Session at all -> check if browser accepts cookies
- Check if you can resume Session::Master, if not: new Session::Master. The master session already sets the cookie.
- Check if you are having an authenticated session, that is have already given login/passw
- If not: get credentials and
- authenticate, getting a Session::GPMS::<YourApp>
- Set the project for this session
once you have and authenticated Session::GPMS::<YourApp> the session can be resumed using Session::GPMS::<[[YourApp]]>->loadSingleton($masterSession);
if it is a singleton session.
API
The API is completely different from the old one, especially when it come to initialization of sessions. The only function that is unchanged is param, fortunately ;-) It can be used to get and set session parameters.
- The function params delivered all parameter values as key value pairs. This function does no longer exist. To replace it:
- get all session parameters by using function getParams to get all parameter names
- use param on each name and store the value
- There is no param_permanent any more, because you don't want it :-| If you do, blame Burkhard and suffer
- the function delete_param removes the param value, which was before done by setting the param to undef