Command context
Commands can obtain information using the command context. Examples of information available include the user's ID, the user object, the language identifier, and the store identifier.
When writing a command, you have access to the command context by calling the getCommandContext() method of the command's superclass. The command context is set to the controller command when the command is invoked by the component facade. A controller command should propagate the command context to any task or controller commands that are invoked during processing.
In previous releases, the information described in the following list was stored in the Command Context object. With the introduction of Business Context in this release, this information are now stored in various business contexts. Command Context becomes a helper class that wraps on top of these business contexts. One can directly retrieve the same piece of information by retrieving the appropriate business context by using the CommandContext.getContext(businessContextName) method. Information that is not available from business contexts, remains available and local to the Command Context object. A command can get the following key information from the command context:
- getUserId() and getUser()
- Gets the user ID or user object the current request should run against. The userId for the current session is stored in the BaseContext. Every BaseContext is associated with an activity identifier which is stored in the session. This session can be persisted in one of two ways: using WebSphere Commerce cookie or a WebSphere Application Server persistent session object. The command context hides the complexity of session management from a command. Instead of retrieving the user ID from the command context, it can also be retrieved from the following code:
- getStoreId(), getStore()
- Gets the store associated with the current request. For Web requests, this method will return the store ID in the URL. If the store ID is not specified in the URL, it can be retrieved from the BaseContext of the activity saved in the session of previous requests. For requests initiated from other channels such as the Sales Center, WebSphere Commerce runtime will first try to retrieve the store ID from the activity data the client passed in with the request. If none is found in the activity data, the store ID stored in the BaseContext of the activity will be used. An alternate way to retrieve the store ID is as follows:
- getLanguageId()
- Returns the language ID that should be used for the current request.
If the language ID is specified in the URL for a Web request or in
the activity data for a Sales Center request, WebSphere Commerce runtime
first validates whether this language ID is supported by the store.
If it is, this language ID will be returned by this method. If it
is not supported, it will then use the language ID stored in the GlobalizationContext
of the activity in the session. However, if this is the first request
and hence no language ID is available in the GlobalizationContext,
of the activity and reuse for subsequent requests.
- The user's preferred language ID is first validated and checked whether it is supported by the store. If it is true, this method will return this language ID.
- If it is not supported, this method will return the store default language.
An alternate way to retrieve the language ID is from the GlobalizationContext:
GlobalizationContext globalizationContext = (GlobalizationContext)getCommandContext().getContext(GlobalizationContext.CONTEXT_NAME); globalizationContext.getLanguageId();
- getCurrency()
- Returns the currency to be used for the current request. The currency is stored in the GlobalizationContext and is derived from the languageId as part of the Globalization framework. Hence, the logic behind this method is similar to that of the getLanguageId() method. The SetCurrencyPreference command should be used to modify the currency in the session.
- Deprecated featuregetCurrentTradingAgreements()
- getCurrentTradingAgreements(CommandContext)
- Returns the set of trading agreements that are used for the current session. This set may be all of the trading agreements to which the user is entitled, or it can be a subset that was defined by the ContractSetInSession command. A command should always get the trading agreement object from the command context to take advantage of the object cache. You can get the current trading agreement by calling the getCurrentTradingAgreements(CommandContext) method.
The command context should be used as a read-only object. You should not call its setter methods.