Difference between revisions of "Session Manager Service"
m |
m (→Sessions and Aggregated Sessions) |
||
| Line 10: | Line 10: | ||
=== Sessions and Aggregated Sessions === | === Sessions and Aggregated Sessions === | ||
| + | Sessions come in four flavors, with each session being distinct. This could be a hassle for anyone wishing to access multiple session data, such as both the environment as well as project-level data. Fortunately most of the session data objects are aggregated to support retrieval of session data for a higher, wider scoped session. The only session that is no aggregated is the environment session as there is no wider scope that the [[EiffelStudio]] environment itself, which encompasses all opened windows. | ||
| + | |||
| + | Here is a brief run through of the level of data that can be read by a type of session: | ||
| + | * A environment-level session will only provide session data exposed in the environment session. | ||
| + | * A project-level session will provide session data exposed in the environment session. | ||
| + | * A window-level session will provide session data exposed in the environment session. | ||
| + | * A project and window level session will provide session data exposed in the window session and then session data exposed in the environment session. | ||
| + | |||
| + | == Using Sessions == | ||
| + | === Session Data Identifiers === | ||
| + | To use a session object to persist and retrieve session data clients will need to define a '''session data id'''. A session data id is a string constant used to identify chunks of session data in the session object so it can be indexed for storage and retrieval between sessions of [[EiffelStudio]]. Strings are inherently problematic for uniqueness and UUID are limiting in readability as well as prohibiting static access to a session data id, if required. As such, string id's were chosen to index session data with a recommended namespacing convention to ensure uniqueness. | ||
| + | |||
| + | ==== Session Data Identifier Recommendations ==== | ||
| + | There is not absolute rules to declaring a session data identifier except that is must be a non-empty attached string object. However to ensure uniqueness the following rules should be adhered to: | ||
| + | |||
| + | And id should... | ||
| + | # Be defined as a namespace using periods (.) to split segments, contains no whitespace and using a reversed company or personal URL domain prefix. For instance all [http://www.eiffel.com Eiffel Software] session data id's start ''com.eiffel''. | ||
| + | # Include a context, such as the name of a tool or region inside [[EiffelStudio]]. | ||
| + | # End with a brief description of the session data. | ||
| + | # Predominantly use alphabetically characters. | ||
| + | |||
| + | As an example, for an [http://www.eiffel.com Eiffel Software] tool (the Error List) perserving the expand error description toggle button state: | ||
| + | |||
| + | <code> | ||
| + | com.eiffel.error_list.expand_errors | ||
| + | </code> | ||
| + | |||
| + | The session data id is split into; reversed URL domain: <code>com.eiffel</code>, tool name: <code>error_list</code> and a session data description: <code>expand_errors</code>. | ||
| + | |||
| + | === Retrieving Sessions === | ||
| + | === Storing Session === | ||
| + | === Determining the Type of Session === | ||
Revision as of 16:46, 28 November 2007
Not Ready for Review: This Page is Under Development!
The Session Manager Service is a graphical-based service used in EiffelStudio to persist and retrieve data between multiple sessions of EiffelStudio. The session manager (SESSION_MANAGER_S) provide access to state persisted sessions in four flavors; Environment, Per-Window, Per-Project and finally Per-Window/Per-Project. The fine grained control of session states proffers a mechanism needed to restore the EiffelStudio as it was left as well as restore a project to exactly how it was left when it was closed.
Contents
Preferences Vs. Session Data
The session manager service is very simple to use and supports arbitrary data types so you may want to jump right in an use it instead of the defining a configurable preference. Session data and preference data have different roles so it is important you choose the right method of data persistence for the task you are trying to perform.
Both session data and preference data are persisted between opened and closed sessions of EiffelStudio, which is the extent at which the are akin. Session data will never been seen by the user whereas preference data can be viewed and modified from within the EiffelStudio IDE. It would not be wise to store a discardable dialog prompt's discarded state in a session because the user may want to revert back to view the dialog prompt at a later time - this is a clear case for a preference. On the other end of the scale, storing a tool's tool bar toggle button's selected state would be ideal to store as session data instead of preference data. That said, storing a toggle button's state in session data might not applicable for the task it's to perform. Note the reference to a tool's tool bar button. A tool is general self-contained and should not affect the behavior of other parts of EiffelStudio. Tool bar buttons on the main tool bar, which actually affect EiffelStudio as a global entity generally should not use a session but a preference instead. The exception to this rule is if data needs to be persisted on a per-window or per-project level.
Sessions and Aggregated Sessions
Sessions come in four flavors, with each session being distinct. This could be a hassle for anyone wishing to access multiple session data, such as both the environment as well as project-level data. Fortunately most of the session data objects are aggregated to support retrieval of session data for a higher, wider scoped session. The only session that is no aggregated is the environment session as there is no wider scope that the EiffelStudio environment itself, which encompasses all opened windows.
Here is a brief run through of the level of data that can be read by a type of session:
- A environment-level session will only provide session data exposed in the environment session.
- A project-level session will provide session data exposed in the environment session.
- A window-level session will provide session data exposed in the environment session.
- A project and window level session will provide session data exposed in the window session and then session data exposed in the environment session.
Using Sessions
Session Data Identifiers
To use a session object to persist and retrieve session data clients will need to define a session data id. A session data id is a string constant used to identify chunks of session data in the session object so it can be indexed for storage and retrieval between sessions of EiffelStudio. Strings are inherently problematic for uniqueness and UUID are limiting in readability as well as prohibiting static access to a session data id, if required. As such, string id's were chosen to index session data with a recommended namespacing convention to ensure uniqueness.
Session Data Identifier Recommendations
There is not absolute rules to declaring a session data identifier except that is must be a non-empty attached string object. However to ensure uniqueness the following rules should be adhered to:
And id should...
- Be defined as a namespace using periods (.) to split segments, contains no whitespace and using a reversed company or personal URL domain prefix. For instance all Eiffel Software session data id's start com.eiffel.
- Include a context, such as the name of a tool or region inside EiffelStudio.
- End with a brief description of the session data.
- Predominantly use alphabetically characters.
As an example, for an Eiffel Software tool (the Error List) perserving the expand error description toggle button state:
com.eiffel.error_list.expand_errors
The session data id is split into; reversed URL domain: com.eiffel, tool name: error_list and a session data description: expand_errors.
