|
|
|
|
|
|
Foundation Classes and Utilities
The following topics are included:
Configuring the JSP Service Manager
Personalization Request Object
Personalization Session Object
Utilities in commerce.util package
The Foundation is a set of miscellaneous utilities to aid JSP and Java developers in the development of personalized applications using the WebLogic Personalization Server. Its utilities include JSP files and Java classes that can be used by JSP developers to gain access to functions provided by the server and helpers for gaining access to Personalization Advisor services.
JSP Service Manager
The JSP Service Manager provides several benefits to JSP developers of non-portal pages. The JSP Service Manager servlet, much like the Portal Service Manager, primarily acts as a traffic cop for the JSP code, including verifying and updating relevant HTTP session information, providing access to useful methods, and providing security services for requests.
Note: Use of the JSP Service Manager in a personalized application is optional, but highly recommended.
The JSP Service Manager works in conjunction with the P13nJspBase class, initializing session data accessed via the P13nJspBase class methods. JSP pages will typically extend P13nJspBase.
The three main benefits of the JSP Service Manager include:
Note: For example usage of the JSP Service Manager and the Base class methods, see the mpbb servlet and buybeans/home.jsp.
Configuring the JSP Service Manager
Register an instance of this servlet in the weblogic.properties file for each Service Manager you deploy. The following is a sample JSP Service Manager servlet registration for a servlet named myServlet.
weblogic.httpd.register.myServlet=com.beasys.commerce.axiom.
jsp.JspServiceManager
weblogic.httpd.initArgs.myServlet=\
homepage=/mydir/home.jsp,\
defaultdest=/mydir/home.jsp,\
workingdir=/mydir/,\
repositorydir=/repository/,\
timeout=-1,\
sessioncomparator=com.beasys.commerce.axiom.jsp.
DefaultSessionComparator,\
groupname=everyone,\
allowautologin=true
|
Parameter Name |
Required |
Description |
|
homepage |
yes |
The home page JSP returned by the system in auto-login. (This page is qualified from yourDocumentRoot as defined in the weblogic.properties file.) |
|
groupname |
no |
The default group name for this servlet instance. |
|
defaultdest |
yes |
The default destination page JSP if there is not a valid session for the user. |
|
timeout |
no |
Time-out for the cookies or session valued in seconds and defaulting to -1. |
|
workingdir |
yes |
The working directory for the implementation that is the path to your JSP pages. Example: |
|
allowautologin |
no |
Determines whether a client with valid cookies can automatically login. The default is false. |
|
repositorydir |
yes |
Location of default files, (gifs, JSP, etc.) |
|
sessioncomparator |
yes |
How to determine if the session is valid. |
Repository
The repository feature allows you to specify a single directory to contain files that otherwise would have to be replicated several times.
The administration pages for components take advantage of the repository feature to store images shared between components. Each HTML reference to an image is wrapped by the ToolsJspBase.fixupRelativeURL method. This method first looks in the path-relative directory for the image specified in the argument. If not found there, the repositorydir specified in the weblogic.properties file (for the wlpsadmin servlet) is searched for the image.
For portals, the default portal (Acme) implementation has its files contained in a folder named repository and specifies a repositorydir=/portal/repository. In an extreme example, a second portal which only differed from Acme in one file, say portal.jsp, would be created by creating a new directory named extremeExample and by adding one file (portal.jsp) to it. All files supporting the extremeExample portal which were not found in its workingdir will be fetched from the repository directory.
HTTP Handling
Both the <pz:div> and <pz:contentselector> tag implementations send HttpRequest and Session information to the Personalization Advisor.
The Personalization Advisor includes helper classes that transform an HttpRequest and Session into Serializable personalization surrogates for their HTTP counterparts. These surrogates are compatible with the Personalization Rules Service which uses these objects to execute classifier and content selector rules.
Personalization Request Object
In order to use HttpRequest parameters in requests to the rules service, they must be wrapped in a Personalization Request object (com.beasys.commerce.axiom.p13n.http.Request) before they can be set on the appropriate AdviceRequest (see the API documentation). While the HttpRequest object can be wrapped by directly calling the Personalization Request constructor, it is recommend that developers use the createP13NRequest helper method on P13NJspBase (com.beasys.commerce.axiom.p13n.jsp.P13NJspBase) for this purpose. See the API documentation for more information.
The tag implementations for the <pz:div> and <pz:contentselector> tags create the Personalization Request surrogate for the HttpRequest before calling the Personalization Advisor bean, so JSP developers need not worry about the details of the Request object. Only developers accessing the PersonalizationAdvisor bean directly need to wrap the HttpRequest object explicitly.
In order to avoid confusing results on getProperty method calls, developers need to know the algorithm used in the getProperty method implementation for determining the value of the property requested . When the Request's getProperty method is called (for example, by a rules engine), the system uses the following algorithm to find the property:
Default Request Property Set
For Rules developers to write rules for classifier rules that contain conditions based on an HttpRequest, there must be a property set defined for the HttpRequest. By default, WLPS 2.0 ships with a default request property set for the standard HttpRequest properties. Developers adding properties to the request programatically, will need to add those properties to the default property set in order for them to be available to the rules editor and service.
The default Request properties include:
|
Request Property Name |
Associated Request Method |
|
Request Method |
request.getMethod() |
|
Request URI |
request.getRequestURI() |
|
Request Protocol |
request.getProtocol() |
|
Servlet Path |
request.getServletPath() |
|
Path Info |
request.getPathInfo() |
|
Path Translated |
request.getPathTranslated() |
|
Locale |
request.getLocale() |
|
Query String |
request.getQueryString() |
|
Content Length |
request.getContentLength() |
|
Content Type |
request.getContentType() |
|
Server Name |
request.getServerName() |
|
Server Port |
request.getServerPort() |
|
Remote User |
request.getRemoteUser() |
|
Remote Address |
request.getRemoteAddr() |
|
Remote Host |
request.getRemoteHost() |
|
Scheme |
request.getAuthType() |
|
Authorization Scheme |
request.getScheme() |
|
Context Path |
request.getContextPath() |
|
Character Encoding |
request.getCharacterEncoding() |
Personalization Session Object
In order to use HTTP Session parameters in requests to the rules service, they must be wrapped in a Personalization Session object (com.beasys.commerce.axiom.p13n.http.Session) before they can be set on the appropriate AdviceRequest (see the API documentation)). While the HttpSession object can be wrapped by directly calling the Personalization Session constructor, it is recommend that developers use the createP13NSession helper method on P13NJspBase (com.beasys.commerce.axiom.p13n.jsp.P13NJspBase)See the API documentation for more information.
The tag implementations for the <pz:div> and <pz:contentselector> tags create the Personalization Session surrogate for the HTTP Session before calling the Personalization Advisor bean, so JSP developers need not worry about the details of the HttpSession object. Only developers accessing the PersonalizationAdvisor bean directly need to wrap the HttpSession object explicitly.
Default Session property set
For Rules developers to write rules that contain conditions based on an HTTP session, there must be a property set defined for the HTTP session. WLPS 2.0 ships with a default session property that contains no values set as a placeholder. There are no default Session property set values. Developers adding properties to the session programatically will need to add those properties to the default property set in order for them to be available to the rules editor and service.
The Personalization Session object retrieves the session values from the Service Manager (see Configuring the JSP Service Manager) for the current thread and clones them so they can be used on a remote machine.
The Personalization Session uses the following algorithm to find a property:
Utilities
You can view more detailed documentation for the utilities listed here in the API documentation.
JspHelper
JspHelper provides get methods to the JspServiceManager URI, the working directory, the home page, and the current page. It also provides set and get methods for session values and JSP destinations.
Note: Some of these methods assume that the JspServiceManager model is being used.
JspBase
JspBase acts as a base class for all JSP pages that use a JspServiceManager. A wide variety of important methods are provided:
P13NJspBase provides convenience methods to developers writing JSP pages (including but not limited to portals and portlets) that included personalized content. It provides methods for wrapping HTTP Request and Session objects into their personalization surrogates, and a method for retrieving the current Profile (User, Group, etc.) for an application.
Note that the Personalization <pz:div> and <pz:contentselector> tags require that the pages they are included in be subclasses of P13NJspBase.
ContentHelper
ContentHelper simplifies the life of the developer using the Content Management component. Methods are provided to get an array of content given a search object, to get the length of a piece of content. Constants for the default Content and Document homes are also provided.
CommercePropertiesHelper
CommercePropertiesHelper allows easy access to the commerce.properties file's properties. Methods are provided to return the values of a given keys as various data types. Also provided is a method to return all keys that start with a given string as a string array. For example, use the method to find all of the keys that start with personalization.portal.
Utilities in commerce.util package
ExpressionHelper
ExpressionHelper handles dealing with Expression, Criteria, and Logical objects. It contains methods for parsing query strings into Expressions, joining Expressions into Logicals, normalizing Expressions, changing Expressions, Logicals, and Criteria into Strings, and turning Expressions into String trees for debugging purposes.
TypesHelper
TypesHelper provides a set of constants corresponding to the types and operators used in the configurable entity properties. Methods are provided to get string representations of the type names, to determine a type from a java.sql.Type, and to get the list of comparison operators for a certain type.
|
|
|
|
|
|
Copyright © 2000 BEA Systems, Inc. All rights reserved.
|