AquaLogic Interaction (formerly called Plumtree Foundation) 6.0 provides wide-ranging backward compatibility with existing UI customizations written for version 5.0.2 or above. In most cases, you only need to recompile existing customization code against the new 6.0 jars/assemblies.
This page explains how to upgrade UI customizations from version 5.0.2 or above to version 6.0. The following sections outline backward compatibility of different UI components, introduce new features that can be used to replace older functionality, and list deprecated APIs and components. For a full list of new features in 6.0, see What's New in G6?
Post-Installation Steps: Upgrading Existing UI Customizations
Multiple Guest Users / Branded Login Pages (Experience Definitions)
Deprecated APIs
After AquaLogic Interaction 6.0 installation is complete, the portal will be installed without any UI customization. (For details on installation, see the Installation Guide for AquaLogic Interaction (Plumtree Foundation) 6.0.) You must follow the steps below to upgrade your existing UI customizations from version 5.0.2 and above to version 6.0.
Note: Some jar/assembly files have changed. Make sure to change your classpath to use the jars/assemblies for version 6.0 when recompiling. In particular, the classes in ptdebug.jar/ptdebug.dll are now part of uiinfrastructure.jar/uiinfrastructure.dll. These classes are supplied only for backward compatibility (see Deprecated APIs: Logging API for instructions on replacing this class).
The contents of 5.0.x plumtreeserver.jar/plumtreeserver.dll are split into plumtreeserver.jar/plumtreeserver.dll and ptportalobjects.jar/ptportalobjects.dll in 6.0. ptportalobjects contains the implementation classes and plumtreeserver contains the interfaces. If the classes you need cannot be found after upgrading, make sure to reference ptportalobjects as well as plumtreeserver. For example, PortalObjectsFactory, which was in plumtreeserver in 5.0.x, is now in ptportalobjects.
The build scripts for the 6.0 UICI work differently that the previous version. The build process now puts the jar/dll under the customer_repo directory, not the same location as the source code, and the install process takes the built jar/dll and adds it to the war file or webapp directory. See Setting Up the Development Portal for details.
If you implemented any custom Activity Spaces in your portal, recompile your code against the new 6.0 jars or .NET assemblies correspondingly. See Custom Activity Spaces for details.
If you implemented any custom PEIs, recompile your PEI code against the new 6.0 jars or .NET assemblies correspondingly. See PEIs for details.
If you implemented a custom navigation solution, see Custom Navigation Schemes for details on upgrading your customizations.
After recompiling your custom code against the new 6.0 jars/assemblies, deploy the jars/assemblies containing your custom code as follows:
Java: Place your custom jars in <PT_HOME>/ptportal/6.0/lib/java, and recompile the portal.war or portal.ear in <PT_HOME>/ptportal/6.0/webapp to include your custom jars (after recompilation).
.NET: Place your custom assemblies in both <PT_HOME>/ptportal/6.0/bin/assemblies and <PT_HOME>/ptportal/6.0/webapp/portal/web/bin
If you are upgrading from 5.0.2 or above, the installer creates a new directory called /settings_customer under the 6.0 <PT_HOME>. This directory contains the upgraded UI customization setting files for your custom Activity Spaces and PEIs. After completing the steps above, copy all the folders and files under /settings_customer to the /settings directory. (For example, all files under settings_customer/portal/dynamicloads/PEIs/ should be copied to settings/portal/dynamicloads/PEIs/.)
In most cases, custom Activity Spaces written for a prior version of the portal will continue to function in 6.0. You must recompile any custom code against the new 6.0 jars or assemblies to ensure that it will work correctly.
Custom Activity Spaces written by extending standard Activity Spaces might not function as expected, since implementation of the super class for the custom implementation may have changed. The list below includes changes to the base Activity Space class (AActivitySpace) after version 5.0.2, including any new methods and modifications to old methods. Note that new methods are newly implemented API methods that provide additional functionality (instead of abstract methods that require subclasses to implement).
AActivitySpace
|
Method |
Added/Modified in Version: |
|
|
6.0 |
|
|
6.0 |
|
|
6.0 |
|
|
6.0 |
|
|
6.0 |
|
|
6.0 |
|
|
6.0 |
|
|
6.0 |
|
|
5.0J |
|
|
5.0J |
|
|
5.0.4 |
|
|
5.0.4 |
|
|
5.0.4 |
|
|
5.0.3 |
|
|
5.0.3 |
|
|
5.0.3 |
No changes were made to IView, IModel, IModelRO, IControl, and IHTTPControl. Any classes implementing these interfaces should work as expected.
Previous implementations of PEIs should continue to work as expected in 6.0. You must recompile any custom code against the new 6.0 jars or assemblies to ensure that it will work correctly. Two new PEIs were added in 6.0: IOpenerActions and ILoginActions2.
IOpenerActions is similar to other existing PEIs. This PEI is called on every request to the Common Opener Activity Space. Conceptually, if all requests to the portal go through the Common Opener, this PEI will become a "universal" PEI. The PEI is implemented after the portal has determined where the user wants to go. You can use the PEI to record the information, redirect based on criteria, etc. The IOpenerActions OnBeforeOpen method executes functionality just before the Common Opener opens an object (or directs to an Activity Space).
ILoginActions2 extends ILoginActions, and contains all methods from ILoginActions plus a new method, OnFailedLoginDoRedirect. This method executes functionality if a user does not login successfully and can be used to redirect to someplace other than the standard login page.
Most existing custom navigation schemes (previously called "pluggable navigation") are supported in version 6.0. However, Isomorphic navigation can not be used due to licensing restrictions. You must rewrite any Isomorphic-related code. For advanced JavaScript navigation schemes, you can use the JSPortalmenu framework; see Advanced JavaScript Navigation Elements. In 6.0, you can use Adaptive Tags to create custom navigation schemes.
Existing CSS customizations should work as expected in version 6.0. Many new customization options are available in version 6.0. For details, see Using Adaptive Styles (CSS Customization) and Modifying Portal Style Sheets.
A common UI customization is branded login pages. In previous versions, this was accomplished through the use of PEIs. The sample code that implements this feature (samplesubportalguests) is still usable, but experience definitions and experience rules provide a more simple and elegant solution.
In version 6.0, you can create multiple guest users in addition to the default guest user that has always existed. This feature allows you to define the portal experience for groups of unauthenticated users. You can accomplish this customization without writing any code. Using the administrative UI, you can create a new experience definition (previously called "subportals") and create experience rules to define the audience. You can choose the layout for the login page/My Page by creating a new guest user associated with the experience definition and configuring the My Page layout for that user.
For example, you might want users who use different URLs to access the portal to see different login pages with different branding. You could create two experience definitions with experience rules that direct users based on the URL used to access the portal (e.g., www.URL-A.com and www.URL-B.com). You would also create two guest users (e.g., Guest-A and Guest-B), associate each user with one of the experience definitions (e.g., URL-A with Guest-A, and URL-B with Guest-B), and modify the layout of each user's My Page. When users view the portal, they would see the My Page defined for the user that is associated with the experience definition that was returned based on the URL used to access the portal (e.g., www.URL-A.com would return Guest-A's My Page).
The portal conditionally selects which experience definition to use for a particular request based on conditions such as URL, IP address, community, and group. You can also create custom conditions. For details, see Customizing Experience Definitions.
The Common Opener is a framework for opening portal objects in the UI in a way that shortens URLs and provides various new features such as the Common Opener PEI, Common Opener plugins, and navigaton by UUID and keyword. The Common Opener is completely backward compatible; 5.0.x-style URLs and older will continue to function. Third-party products that track portal usage based on URL information might need to be adjusted after upgrading to 6.0.
The example URLs below both open a data source in mode 2 (edit).
5.0.x:
http://www.myportal.com/portal/server.pt?space=Opener&control=OpenObject&in_hi_userid=243&in_hi_ClassID=35&in_hi_ObjectID=104&in_hi_OpenerMode=2
6.0:
http://www.myportal.com/portal/server.pt?space=Opener&clsID=35&objID=104&mode=2
For details, see Using the Common Opener.
Some APIs have been deprecated in version 6.0.
The PTDebug style of logging continues to work, but this class is deprecated. The recommended style is to use OpenLog as shown below. The key difference between the old logging style and the new is the use of a different set of classes. Essentially, OpenLog contains all the functionality PTDebug has with minor name differences. For details on using logging, see Debugging Using ALI Logging Utilities.
OLD PTDebug logging style:
Java:
import
com.plumtree.debug.*;
if (PTDebug.IsFatalTracingEnabled(Component.Portal_UI_Infrastructure))
{
PTDebug.Trace(Component.Portal_UI_Infrastructure, TraceType.Fatal, "Error
Message …“, exception);
}
.NET:
using
com.plumtree.debug;
if (PTDebug.IsFatalTracingEnabled(Component.Portal_UI_Infrastructure))
{
PTDebug.Trace(Component.Portal_UI_Infrastructure, TraceType.Fatal, "Error
Message …“, exception);
}
NEW OpenLog logging style:
Java:
import
com.plumtree.openlog.*;
private static OpenLogger log = OpenLogService.GetLogger(OpenLogService.GetComponent("UI_Infrastructure"),
"location");
log.Fatal(exception, “Error Message …”);
.NET
using
com.plumtree.openlog;
private static OpenLogger log = OpenLogService.GetLogger(OpenLogService.GetComponent("UI_Infrastructure"),
"location");
log.Fatal(exception, “Error Message …”);
In 6.0, Pages are objects, resulting in significant changes to the APIs surrounding Pages. All deprecated APIs work with 6.0, but may not perform as well as the APIs that replace them. Deprecated interfaces will be eliminated in a future version of the portal. Any custom code that uses the deprecated APIs should be updated. (For a list of deprecated APIs and methods, see API Changes below.)
Note: There are no longer any Pages with a negative ID.
In previous versions, IPTMyPortal was used to represent a Page. The IPTMyPortal interface and all associated methods are deprecated in 6.0. Use IPTPage or IPTPageInfo instead.
IPTPage extends IPTObject and is used to represent a Page. IPTPage should only be used when a Page is being edited or created, otherwise IPTPageInfo should always be used.
IPTPageInfo represents a cached version of a Page.
In 6.0, Pages are created like any other object. To add a new page, call Create() on the Object Manager for Pages (instead of calling AddPage() on IPTCommunity or IPTMyPages).
To create a new Community Page, pass in the Folder ID that contains the Community to which the Page should be added:
IPTPage
ptCommunityPage = (IPTPage)ptSession.GetPages().Create(nCommunityFolderID);
To create a new My Page, pass in the negative of the ID of the User to whom the My Page belongs:
int
nUserID = ptSession.GetSessionInfo().GetCurrentUserID();
IPTPage ptMyPage = (IPTPage)ptSession.GetPages().Create(-nUserID);
To retrieve an existing IPTPage, use the Pages Object Manager:
IPTObjectManager
ptomPages ptSession.GetPages();
IPTPage ptPage = (IPTPage) ptomPages.Open(nPageID,false);
There are several ways to retrieve an IPTPageInfo. Pages are contained by Page Containers, such as a Community or a User’s My Pages. IPTCommunity and IPTMyPages both extend the interface IPTPageContainer, which includes the method GetPage(int nPageID). To retrieve the first page in a Community or set of My Pages, substitute nPageID with "0".
The following code retrieves a Page in a Community:
IPTObjectManager
ptomCommunities = ptSession.GetCommunities();
IPTCommunity ptCommunity = (IPTCommunity)ptomCommunities.Open(nCommunityID,false);
IPTPageInfo ptPageInfo = ptCommunity.GetPage(nPageID);
The following code retrieves a User’s My Page:
IPTMyPages
ptMyPages = ptSession.GetMyPages();
IPTPageInfo ptPageInfo = ptMyPages.GetPage(nPageID);
You can also retrieve a cached Community Page from a cached Community as shown below:
IPTCommunityManager
ptomCommunities = (IPTCommunityManager) ptSession.GetCommunities();
IPTCommunityInfo ptCommunityInfo = ptomCommunities. CachedOpenCommunityInfo(nCommunityID,false);
IPTPageInfo ptPageInfo = ptCommunityInfo.GetPage(nPageID);
You can retrieve a cached My Page from a User’s IPTSessionInfo:
IPTSessionInfo
ptSessionInfo = ptSession.GetSessionInfo();
IPTPageInfo ptPageInfo = ptSessionInfo.GetCurrentMyPage(nPageID);
If you do not know which Community contains the Community Page, you can get the Page directly from the Page Manager:
IPTPageManager
ptomPages = (IPTPageManager)ptSession.GetPages();
IPTPageInfo ptPageInfo = ptomPages.CachedOpenPageInfo(nPageID,false,false);
For a summary of deprecated methods, see the next section. For a complete list of methods, see the API documentation.
The following is a summary of the changes and additions to APIs for IPTPreferencesContext, IPTPageContainer, IPTCommunity, IPTMyPages, IPTGadgetGateway, IPTCommunityManager, IPTPageTemplate, IPTGadgetInfo, IPTCommunityInfo, and IPTSessionInfo.
The IPTPreferencesContext interface provides methods for setting, removing, and looking up preferences. In previous versions, these methods were on the IPTMyPortal interface. The IPTPreferencesContext interface is extended by IPTPageContainer (which is extended by both IPTCommunity and IPTMyPages). The signature for these methods has also been changed to make them easier to use: pass in a Portlet ID (0 if the preference is not a portlet preference), and a PT_PREF_TYPES (PT_PREFTYPE_CURRENT_USER if the preference is for the current user or PT_PREFTYPE_ALL_USERS if the preference is for all users). For a full list of methods, see the API documentation.
The IPTPageContainer interface extends IPTPreferencesContext and provides the following methods:
QueryPages
AssignPages
GetPage
The following changes were made to the IPTCommunity interface:
QueryPages, RemovePage have been moved into IPTPageContainer.
OpenPage is deprecated. Use GetPage (inherited from IPTPageContainer).
AddPage(String, int, int, int), which creates a page and adds it to the Community, is deprecated. Use Create(int) on the Object Manager for Pages and pass in the Folder ID of the Community.
ResetPageName, ResetPageType, and ResetPagePageTemplateID are deprecated. Use SetName, SetPageType, and SetPageTemplateID directly on the IPTPage.
ResetPageURL is deprecated, but will not be replaced, this feature is being eliminated.
GetInheritCommunityTemplate and SetInheritCommunityTemplate were added. GetInheritCommunityTemplate returns a Boolean value, true if the Community inherits its Community Template, false if not. SetInheritCommunityTemplate sets whether a newly created community inherits its Community Template or not. (Calling this method after the Community is stored for the first time will have no affect.)
The following changes were made to the IPTMyPages interface:
QueryPages, RemovePage have been moved into IPTPageContainer.
OpenPage is deprecated. Use GetPage (inherited from IPTPageContainer).
AddPage(String, int), which creates a page and adds it to the user’s My Pages, is deprecated. Use Create(int) on the Object Manager for Pages, and pass in the negative of the ID of the User.
ResetPageName and ResetPageType are deprecated. Use SetName and SetPageType directly on the IPTPage.
ResetPageURL is already deprecated; this feature is being eliminated.
QueryMemberships, QueryAvailableCommunities, JoinCommunity, QuitCommunity, and QueryMandatoryTabs are deprecated, because it is not intuitive to have Community methods on a My Pages object. Use the corresponding methods on IPTCommunityManager.
FlushCaches is deprecated. Use FlushMandatoryGadgetsCache and IPTCommunityManager.FlushMandatoryTabsCache.
The following changes were made to the IPTGadgetGateway interface:
OpenGadgetInfoFromPage(int, IPTMyPortal) is deprecated. It will not be replaced. Use OpenGadgetInfo(int nPortletID, int nPageID, int nPageContainerClassID, int nPageContainerObjectID).
OpenGadgetInfo(int nPortletID, int nPageID, int nCommunityID) is deprecated. Use OpenGadgetInfo(int nPortletID, int nPageID, int nPageContainerClassID, int nPageContainerObjectID).
GetContent has four variations that take a Community ID. These are all deprecated and replaced with equivalents that take a Container Class ID and Object ID.
The following methods were moved to the IPTCommunityManager interface from IPTMyPages: QueryMemberships, QueryAvailableCommunities, JoinCommunity, QuitCommunity, QueryMandatoryTabs, and FlushMandatoryTabsCache.
The following methods were added to the IPTPageTemplate interface to allow the default page name to be localized: GetDefaultPageLocalizable, GetLocalizedDefaultPageNames, SetLocalizedDefaultPageNames, GetLocalizedDefaultPageName, GetIsDefaultPageLocalized, SetIsDefaultPageLocalized, GetDefaultPagePrimaryLang, and SetDefaultPagePrimaryLang.
In the IPTGadgetInfo interface, GetCommunityID is deprecated. Use GetPageContainerClassID and GetPageContainerObjectID.
In the IPTCommunityInfo interface, OpenPage is deprecated. Use the new method GetPage.
In the IPTSessionInfo interface, the method GetCurrentMyPage was added.