Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun Java System Portal Server 6 2005Q1 Desktop Customization Guide 

Chapter 2
Modifying the Default Sample Portal

This chapter contains the following sections:


Introduction

The Portal Server software includes a sample portal that demonstrates the Portal Server software features. The sample portal requires customization before deploying the portal because the sample portal does not have the custom content that you may require in your deployment environment.


Editing the Default Sample Portal Files

Do not directly edit any of the files that make up the sample portal (display profile XML, JSP, and template files). Instead, make a copy of the sample portal to a new directory and then modify those copied files. In this way you preserve the integrity of the sample portal. Additionally, if you later apply a patch to the Portal Server, you won’t loose any changes you might have made to the sample portal files, as the patch would only overwrite the initially installed sample files.


Changing the Desktop Type

You should also create a custom Desktop type for your users. The Desktop type attribute of the Desktop service is a comma-separated string. It is still a string type, but the Desktop uses it as an ordered Desktop type list. The list is used by the Desktop lookup operation when searching for templates and JSPs. The lookup starts at the first element in the list and each element represents a sub directory under the Desktop template base directory. If a template is not found in the first directory, then it proceeds to the next one in the list. This continues until the item is found (or not), for all Desktop type elements in the list.

If the default directory is not included in the list, it will be added at the end of the list implicitly. For example, if the Desktop type is sampleportal, the target template will be searched in the sampleportal sub directory, then the default sub directory.

By default, if the sample portal is installed, then the Desktop type attribute, sunPortalDesktopType, is set to sampleportal, meaning files are retrieved from the sampleportal subdirectory. If the sample portal is not installed, then the Desktop type attribute value is set to default. The authless user is created as part of the sample portal, and the Desktop type for the authless user is set to anonymous,sampleportal.

You can define a new set of templates by creating a new directory under the /etc/opt/SUNWps/desktop/ directory, placing your template files in this directory, and making this directory the Desktop Type attribute for that organization.

    To change the Desktop type
  1. Create a new subdirectory in the /etc/opt/SUNWps/desktop directory, or whatever directory templateBaseDir specifies in the desktopconfig.properties file.
  2. For example:

    mkdir /etc/opt/SUNWps/desktop/sesta

  3. Manually copy only the template files that you wish to modify to the new directory location.
  4. For example, if your Desktop type will modify content.jsp file for JSPProvider, copy this file to /etc/opt/SUNWps/desktop/sesta/JSPProvider/content.jsp, and customize the file for the new Desktop type in that location.

  1. Use the Access Manager software administration console to change the value of the Desktop Type attribute for the subdirectory created in Step 1.
  2. As this attribute is dynamic, you need to change it everywhere that it appears (organization, sub-organization, role, and user). Changing the Desktop Type at the organization level will not necessarily be reflected at the user level. This will be the case only if the user has not overwritten the Desktop Type in which case the Desktop Type value will be inherited from the organization level. If the user defines the Desktop Type at the user level, the value will remain the same even if the Desktop Type is changed at the organization level.

For more information on the Desktop attributes, see Portal Server Technical Reference Guide. See the Portal Server Administration Guide for more information on editing the Desktop attributes.


Restoring the Default Sample Portal Settings

To re-load the default (original) display profile for the sample portal providers, the dp-providers.xml and dp-org.xml files (in PortalServer-base/samples/desktop directory) must be reloaded. The dp-providers.xml file goes in the global level and the dp-org.xml file goes in the organization level. For example, type:

PortalServer-base/bin/dpadmin modify -u "uid=amAdmin,ou=People,dc=sesta,dc=com" -w password -g PortalServer-base/samples/desktop/dp-providers.xml

PortalServer-base/bin/dpadmin modify -u "uid=amAdmin,ou=People,dc=sesta,dc=com" -w password -d "dc=sesta,dc=com" PortalServer-base/samples/desktop/dp-org.xml


Deriving the Sample Desktop

The container architecture uses the various containers, and JavaServer Pages™ (JSP™) or template files, to display the Desktop, and to build a hierarchy of containers that organize the Desktop content. Channels are defined at the global display profile level and are referenced by all the containers.


Determining the User’s Default Desktop

The Portal Server software determines the user’s default container by examining the Default Channel Name attribute for the Desktop page in the Access Manager software administration console.

When you install the sample portal, by default, the default channel is set to JSPTabContainer. Users can view this portal by typing:

http://hostname:port/portal/dt

You can easily view each sample portal Desktop by typing in the appropriate URL.


Note

The Desktop service uses a dynamic attribute, SunPortalDesktopDefaultChannelName, to specify the default channel to execute when accessing the Desktop. This attribute is displayed as Default Channel Name in the administration console. This attribute is only used when the provider=name URL parameter is not specified. The default channel service attribute can be overridden by passing to the Desktop servlet the provider parameter and setting it to the name of a channel. Once the provider=parameter is passed to the Desktop, this value becomes the new default channel. The service attribute is no longer used for the duration of the current user’s session.

Setting the service attribute for the default channel is useful in simple scenarios when you need to set a default channel per organization or per role. In situations where you need to set the default channel based on some programmatic logic, you should use a routing container.

A routing container is a channel that reads a display profile property specifying the user’s preferred default Desktop channel to determine the Desktop to present. See the Portal Server Developer’s Guide for more information on developing a custom routing container.




Previous      Contents      Index      Next     


Part No: 817-7694.   Copyright 2005 Sun Microsystems, Inc. All rights reserved.