Appendix B   Sample Tasks


The various sections in this appendix include sample tasks for:

• Configuring the Attributes

• Customizing the Templates

• Adding a New ClientType

• Customizing the Client Detection Interface

• Creating Help Links

• Making a Provider Client Aware

• Implementing the Client Data API

Use these sample configuration scenarios to set up and customize your Mobile Access Pack server. Note that many of the tasks discussed in this chapter can be performed from the administration console and for more information on performing these tasks from the administration console, please refer to the Mobile Access Pack Administration Guide.

Configuring the Attributes

This section discusses how to modify existing component attributes and how to add new attributes to a component.

Modifying the Attributes

This section discusses how to modify attributes in the component XML file. To modify the attributes:

1. Log in to the machine running the Mobile Access Pack server and become superuser.

2. Enter:

   # <iPS_install_base>/SUNWips/bin/ipsadmin get component <component_name> > <filename>

   Here, replace:

   • iPS_install_base with the installed location of the iPlanet Portal Server

   • component_name with the name of the profile component to customize. For example, replace component_name with iwtMailProvider to customize the mail channel.

   • filename with the name of the file to redirect the output to

3. Open the file and edit the attributes in the file containing the component attributes.

   This is the file to which the ipsadmin command output was directed to.

4. Save and close the file.

5. Enter:

   # <iPS_install_base>/SUNWips/bin/ipsadmin change component <component_name> <filename>

   Here, replace:

   • iPS_install_base with the installed location of the iPlanet Portal Server.

   • component_name with the name of the component that was customized.

   • filename with the name of the file that contains the modified attribute values.

6. Restart the server.

Adding an Attribute

To add an attribute to a Mobile Access Pack server component:

1. Log in to the machine running the Mobile Access Pack server and become superuser.

2. Enter:

   # <iPS_install_base>/SUNWips/bin/ipsadmin delete component <component_name>

   Here, replace:

   • iPS_install_base with the installed location of the iPlanet Portal Server

   • component_name with the name of the profile component to update. For example, replace component_name with iwtClient.

   This removes the current portal profile for the component.

3. Open the component XML file in /etc/opt/SUNWips/xml directory and add the new attribute to this file.

   For backup purposes, make a copy of the original XML file before adding the new attribute. For example, enter:

      # cp /etc/opt/SUNWips/xml/iwtClient.xml OldiwtClient.xml

4. Import the newly updated component XML file in to the portal profile settings. For example, to import, enter:

      # <iPS_install_base>/SUNWips/bin/ipsadmin -import <component_name>.xml

   Here, replace:

   • iPS_install_base with the installed location of the iPlanet Portal Server

   • component_name with the name of the profile component. For example, replace component_name with iwtClient.

5. Restart the server.

Customizing the Templates

When modifying template files, please follow the following recommendations:

1. Log in to the Mobile Access Pack server and become superuser.

2. Create a directory similar to the default directory in /etc/opt/SUNWips/desktop/default. For example:
   1. Change directories to /etc/opt/SUNWips/desktop/default.

   2. Enter:

            # mkdir NewDesktop

3. Copy files from the default directory in /etc/opt/SUNWips/desktop/default over to the new directory. For example, enter:

      # cp -R default/* NewDesktop

   Although you can copy all the files under the default directory, we recommend you only copy files you wish to change and/or customize over to the NewDesktop directory. When copying files, use the same directory hierarchy to the template files.

4. Modify the copied files in the new directory.

   Do not modify files under the default directory.

5. Modify the iwtDesktop-type attribute. That is, enter the path to the directory that contains the customized desktop templates in this attribute. For example, specify the path to the NewDesktop.

   The path must be relative to /etc/opt/SUNWips/desktop. If the server cannot find the required files under the directory you specify here, it will default to the files in the default directory.

6. Restart the server.

   
   

   ---

   Note	Do not modify the original template files in the default directory as this will break uninstall and/or upgrade.

   ---

   
   

Adding a New ClientType

The Mobile Access Pack server includes support for generic HTML, cHTML, and WML clients. In order to extend support for other markup languages (or clientTypes), for example, XYZ markup language, refer to the sample XYZ configuration scenario in this section.

For information on adding a clientType from the administration console, please see Chapter 3 in the Mobile Access Pack Administration Guide. From the command line:

1. Log in to the Mobile Access Pack server machine and become super user.

2. Change directories to /etc/opt/SUNWips.

   Develop the appropriate templates to translate the content produced by the Mobile Access Pack server providers for display on an xyz client.

Configuring Authentication for XYZ Clients:
Assuming that XYZ clients are not a derivative of WML or cHTML:

---

Note	If the XYZ client is a derivative of cHTML or WML, create the xyz directory under WML or cHTML (accordingly) and copy only the files you wish to customize for the XYZ clientType into the xyz directory.

---

1. Change directories to auth/default and create a directory for XYZ. That is, enter:

         # cd auth/default

         # mkdir xyz

2. Copy files from either html, wml, or chtml directory to the xyz directory. That is, enter:

         # cd xyz

         # cp -R ../chtml/* .

   Do not modify or change the name of the files copied from the chtml directory.

3. Modify and save the xyz template files to support XYZ clients.

   See "Authentication Template Files" for more information on template files in this directory.

4. Specify the supported authentication modules for the XYZ clients. That is:

   From the Administration Console:

   1. Log in to the administration console and select Manage Platform Settings.

   2. Select Authentication and Show Advanced Settings.

   3. Specify the supported authentication modules for XYZ clients under Supported Auth Modules for Clients.

      For example, enter xyz|Ldap and select Add.

   4. Select Submit.

   From the command line, incorporate the supported authentication modules for XYZ clients in the iwtAuth-supportedAuthModules attribute using the ipsadmin command.

   See Chapter 8 "Attributes and Schemas" for more information on modifying this attribute.

5. Specify the loginWorkerClass for XYZ clients. That is, modify the iwtAuth-loginWorkerClasses attribute value to include the newly added clientType. See iwtAuth-loginWorkerClasses for more information.

   See Chapter 8 "Attributes and Schemas" for more information on this attribute.

Configuring Channels for XYZ clients:
Do not modify files in the /etc/opt/SUNWips/desktop/<default> directory. See "Modifying the Attributes" for more information.

1. Change directories to desktop/<NewDesktop>/. That is, enter:

         # cd /etc/opt/SUNWips/<NewDesktop>

2. Create a XYZ directory under the provider directory.

   For each provider content that will be delivered to the XYZ client, create a subdirectory for the XYZ client under that provider directory. For example, to provide mail channel on the XYZ client:

   1. Change directories to the mail provider directory. Enter:

               # cd iwtMailProvider

   2. Create a directory for XYZ clients here. Enter:

               # mkdir xyz

   3. Copy files from html, chtml, or wml directory over to the xyz directory. For example, enter:

               # cd xyz

               # cp -R ../chtml/* .

   4. Modify and save the template files to support clients that use the XYZ markup language.

      Refer to Chapter 5 "Application JSPs" and Chapter 4 "Content Provider Template Files" for more information on these template files.

3. Modify the iwtClient-clientTypes attribute to define device characteristics of XYZ clients.

   See "Client Detection Module Attributes" and modify this attribute accordingly. For example, to modify this attribute, enter:

   <VAL>clientType=XYZ|userAgent=XYZ|contentType=text/xyz|fileIdentifi er=xyz|filePath=my_xyz|charset=ISO-8859-1;UTF-8</VAL>

   This adds the XYZ clientType and includes important client specific information to support the XYZ clients.

Enabling Content Delivery for XYZ Clients:
In order to set up and deliver content via channels to the newly configured XYZ client:

1. Log in to the Mobile Access Pack server machine and become super user.

2. Modify the iwtDesktop-clientAllProviders, iwtDesktop-clientUserSelectedProviders, and iwtDesktop-clientChannelListModules attributes. To modify, see "Configuring the Attributes" for more information. See also "Desktop Attributes" for information on:
   • iwtDesktop-clientAllProviders and enter:

           xyz|iwtUserInfoProvider;iwtXMLProvider;iwtPostitProvider

     This indicates that a user information channel, an XML channel, and a PostIt channel are supported for a xyz client.

   • iwtDesktop-clientUserSelectedProviders and enter:

           xyz|iwtUserInfoProvider

     This makes the xyz client available to the end user from the Mobile Devices page on their desktop.

   • iwtDesktop-clientChannelListModules and enter:

     xyz|com.iplanet.portalserver.desktop.util.channellist.ClientChannel List.

     This adds the clientType to the Client Specific Channel List Module.

The xyz client is now displayed in the Mobile Devices page from the user's desktop page and it has access to all of the channels that were made available to it.

Customizing the Client Detection Interface

This section provides instructions for:

• Developing a Customized Client Detector

• Modifying the Default Client Detector

Developing a Customized Client Detector

Client detection can be achieved by creating a client detector object that will:

1. Parse data from the HTTPServletRequest of the requesting client

2. Perform some method of matching based on the stored clientTypes and their corresponding properties

In order to develop such a client detector, the client detection class must:

• Implement an interface called ClientDetectionInterface.

• Contain a method called getClientType which will be passed to the HTTPServletRequest from the requesting client.

The class can then look at the header information provided by the client in it's request, match it against the clientType and its device specific characteristics saved in the Client Data, and return the clientType that it has received from the Client Data object.

Sample Client Detection Interface
public class SampleCDM implements ClientDetectionInterface {

/*

* Detects the client type based on the Request

* @param request HttpServletRequest

* @return a String representing the clientType

* @exception ClientDetectionException if there is an error retrieving the client data.

*/

   public String getClientType(HttpServletRequest request) throws

   ClientDetectionException{

   }

   public String HTTPheaderCheck(String HTTPheader){

   }

}

See Appendix A "API Descriptions" for detailed information on the Mobile Access Pack server client detection interface. After developing the client detector class:

1. Change the profile settings to enable client detection using the newly developed class. To change:
   1. Modify the iwtAuth-clientDetectionEnabled attribute value.

      See "iwtAuth-clientDetectionEnabled" and modify this attribute value by referring to "Configuring the Attributes".

   2. Modify the iwtAuth-clientDetectionClass attribute to use the newly developed client detector class.

      See "iwtAuth-clientDetectionClass" for more information on this attribute and modify this attribute value by referring to "Configuring the Attributes".

2. Ensure that the class is placed in the webserver's classpath.

3. Restart the server.

Modifying the Default Client Detector

By default, the Mobile Access Pack client detection module performs a substring matching to match the requesting client's HTTP header value (or userAgent) against the Client Data objects. To change the module to use regular expression matching:

1. Write a class that makes use of the ClientDetectionInterface.

   public class SampleCDM implements ClientDetectionInterface {

      public String getClientType (HttpServletRequest req) throws

      ClientDetectionException{

         // get the user-agent from the HttpServletRequest

         String clientType = userAgentCheck(String user-agent);

         if ((clientType.equals("")) || (clientType == null))

            return

            Client.getDefaultInstance().getProperty("clientType");

         else

            return clientType;

         }

      public String userAgentCheck(String userAgent){

         // Implement the regular expression checking within this

         // method

         // return the clientType if it matches, empty String if it

         // does not match

      }

   }

2. Ensure that the class is placed in the webserver's classpath

3. Login to the Administration Console and select Manage Platform Settings.

4. Select Authentication and select Show Advanced Settings.

5. Ensure that Client Detection is enabled.

6. Add the customized Client Detection class into the Client Detector class attribute.

7. Restart the server.

Creating Help Links

In order to provide assistance with content to the mobile device users, the Mobile Access Pack server provides a mechanism to display help for the user's home page and for each channel in the appropriate markup language.

Enabling Help Content Delivery on a Mobile Device

This section discusses how to deliver help content to a mobile device user.

Each provider uses the Provider API (PAPI) interface to find which methods are called by the various desktop classes to create the desktop. The two methods, hasHelp() and getHelp(), are used by the Mobile Access Pack server to display a help link for each provider. See "Client Help" for more information on these methods.

When configuring the help link for a channel:

1. Create the hasHelp() and getHelp() methods for each supported provider. Use the sample methods below when writing these methods.

   The Mobile Access Pack server providers include these methods in the class file. Develop only the help content for the Mobile Access Pack server providers and proceed to Step 2. The sample methods discussed here are only for providers who do not have the help mechanism built into them.

Sample hasHelp() method
The hasHelp() method must return the boolean value of true or false depending on whether or not the attribute iwtComponent-clientHelpLinks is found in the profile for the component.

public class WirelessSampleProvider() extends SampleProvider{

   public boolean hasHelp(){

      Vector clientLinks = getListProperty("iwtSampleProvider",

         "clientHelpLinks", null);

      if (clientHelpLinks == null){

         return false;

      }

      for (Enumeration e = clientHelpLinks.elements();

         e.hasMoreElements();){

         if ((String)e.nextElement() == clientType){

            return true;

         }

      }

      return false;

   }

}

Sample getHelp() method
The getHelp()method must return the URL that corresponds to the specified clientType.

public class SampleProvider() extends ProfileProviderAdapter{

   public boolean getHelp(){

      Vector clientLinks = getListProperty("iwtSampleProvider",

         "clientHelpLinks", null);

      if (clientHelpLinks == null){

         return false;

      }

      for (Enumeration e = clientHelpLinks.elements();

         e.hasMoreElements();){

         String link = (String)e.nextElement();

         String url = "";

         if (link.indexOf(clientType) > -1){

            StringTokenizer tok = new StringTokenizer(link, "|");

            String temp = tok.nextToken();

               if (temp.equals(clientType)){

                  url = tok.nextToken();

               }

         }

      }

      String userLocale = getStringProperty("iwtUser", "locale",

         "en_US");

      String localizedUrl = "/docs/" + userLocale+ "/online_help/"

         + url;

      String proto = SystemProperties.get("ips.server.protocol");

      String host = SystemProperties.get("ips.server.hostname");

      String port = SystemProperties.get("ips.server.port");

      URL help = null;

      try{

         help = new URL(proto, host, Integer.parseInt(port),

            localizedUrl);

      } catch (MalformedURLException mue){

         debug.error("Unable to create help link");

         help = null;

      }

      return help;

   }

}

2. Add the clientHelpLinks attribute (see <channelName>-clientHelpLinks for more information) to the profile for the component. To add, refer to "Configuring the Attributes" for more information.

3. Restart the server.

   Help is now made available in the user's mobile device home page under the Options selection.

Developing and Storing the Help Files

Develop help content for all supported clientTypes and their channels and store the files under <iPS_install_base>/SUNWips/public_html/docs/<locale>/online_help.

Making a Provider Client Aware

This section discusses how to make a provider serve content to multiple clientTypes (such as cHTML and WML). In order to service multiple clients, a provider must become aware of the type of client requesting its service; that is, a provider must become client aware. Use the sample set up scenario in this section when making a provider client aware.

The sample HelloWorld3 Provider (HelloWorld3Provider) in (<iPS_install_base>/SUNWips/sample/desktop/classes/com/iplanet/portalserver/providers/helloworld3) is the provider used in our example here.

In this example:

Content Delivery
The WirelessHelloWorld3Provider uses template files to display its content and to determine its presentability. That is, if template for a specific clientType is available, the WirelessHelloWorld3Provider will support display of content on that clientType.

Package
The WirelessHelloWorld3Provider resides in the same package as the other iPlanet Portal Server providers:

   package com.iplanet.portalserver.providers.helloworld3;

Inheritance
Inheritance provides the provider with the functionality of the Provider API (PAPI). The WirelessHelloWorld3Provider inherits from the existing HelloWorld3Provider provider.

public class WirelessHelloWorld3Provider extends HelloWorld3Provider

Class Variables
The WirelessHelloWorld3Provider contains the following class variables and includes a variable for the one generic content template that is used in the getContent() method.

private static final String contentTemplate = "display.template";

private String clientType = null;

private boolean isGenericHTML;

private boolean isPresentable;

Init Method
public void init(String n, Session s) throws ProviderException

ClientType
ClientType refers to the list of clients (such as HTML, cHTML, and/or WML) supported by the provider. Retrieval of the clientType value stored in the session is necessary to determine the value of the isGenericHTML attribute. This attribute is used to determine whether or not to invoke the superclass method.

clientType = "";

isGenericHTML = false;

try {

   clientType = s.getProperty("ips.clientType");

   isGenericHTML = (Client.getInstance(clientType).

      getProperty("genericHTML")).equals("true");

} catch (SessionException se) {

   throw new ProviderException("Unable to retrieve Session client

      type");

} catch (ClientException ce) {}

Presentability
Presentability refers to determining whether or not to service the client based on whether or not the requesting clientType is supported by the provider. That is, the WirelessHelloWorld3Provider is presentable if a template is found for the requesting clientType.

Presentability, in this example, is based on the following logic:

* If the content template is found, then the channel is presentable to the client.

Or,

* If isGenericHTML is true, then the superclass method will be used, and the client is assumed to be presentable.

isPresentable = true;

StringBuffer template = null;

if (!isGenericHTML) {

   try {

      template = getTemplate(contentTemplate);

   } catch (ProviderException e) {

      isPresentable = false;

   }

   if (template == null) {

      isPresentable = false;

   }

}

Content Retrieval
Content retrieval is based on the getContent() method.

public StringBuffer getContent(Map m) throws ProviderException

First, check to see if the client is a generic HTML client, defined by the isGenericHTML attribute. If the boolean value is true, then invoke the superclass getContent() method.

if (isGenericHTML)

   return super.getContent(m);

If the value of the isGenericHTML variable is false, then retrieve the client specific content template. The getTemplate() method will use the client's filePath attribute in the Client Data to locate the template.

StringBuffer content = getTemplate(contentTemplate);

return content;

The following will determine if the provider is presentable:

public boolean isPresentable() {

   return isPresentable;

}

The following method, required as defined by the Provider interface, provides the provider with a mechanism to indicate whether or not it is editable from a particular clientType. If this method returns true, then there must be a client aware getEdit() method.

/*

* Determine if the provider is editable

* @return boolean

*/

public boolean isEditable() {

   if (isGenericHTML)

   return super.isEditable();

   return false;

}

Installation
It is assumed that the existing iwtHelloWorld3Provider component has been installed on the system.

Sample iwtHelloWorld3Provider Template Files
Create the client specific template files for this provider. The template files are typically located in /etc/opt/SUNWips/desktop/default. In order to set up the template files, enter:

# mkdir iwtHelloWorld3Provider

# mkdir /iwtHelloWorld3Provider/wml

# touch /iwtHelloWorld3Provider/wml/display.template

# mkdir /iwtHelloWorld3Provider/chtml

# touch /iwtHelloWorld3Provider/chtml/display.template

The display.template file contains something similar to the following:

# cat ./iwtHelloWorld3Provider/wml/display.template

<p>

Wireless Hello World #3!

</p>

# cat ./iwtHelloWorld3Provider/chtml/display.template

Wireless Hello World #3!

<br>

Setup

1. Log in to the Mobile Access Pack server administration console and select Manage Domains.

2. Select the domain and expand Applications.

3. Select Desktop and select iwtHelloWorld3Provider from the list of Available Channels.

4. Select the Edit Channel button to display the profile settings for the provider.

5. Change the Provider Class Name to com.iplanet.portalserver.providers.helloworld3.WirelessHelloWorld3Provider and select Submit.

   This will enable use of the new class that provides the client awareness.

6. Select Show Advanced Options and modify the Client Specific Available Providers for the clients supported by this provider. For Example,

      WML|iwtHelloWorld3Provider

      cHTML|iwtHelloWorld3Provider

7. Select Submit.

Sample WirelessHelloWorld3Provider Class File
Create the WirelessHelloWorld3Provider class file or modify a copy of the HelloWorld3Provider class file in iPS_install_base/SUNWips/sample/desktop/classes/com/iplanet/portalserver/providers/helloworld3 directory.

package com.iplanet.portalserver.providers.helloworld3;

import java.util.*;

import com.iplanet.portalserver.client.Client;

import com.iplanet.portalserver.client.ClientException;

import com.iplanet.portalserver.providers.helloworld3.HelloWorld3Provider;

import com.iplanet.portalserver.providers.ProfileProviderAdapter;

import com.iplanet.portalserver.providers.ProviderException;

import com.iplanet.portalserver.session.Session;

import com.iplanet.portalserver.session.SessionID;

import com.iplanet.portalserver.session.SessionException;

/*

The following example shows how to use the existing HelloWorld3Provider to create a new Mobile Access Pack provider that is client aware.

*/

public class WirelessHelloWorld3Provider extends HelloWorld3Provider{

   private static final String contentTemplate = "display.template";

   private String clientType = null;

   private boolean isGenericHTML;

   private boolean isPresentable;

/*

* Constructor

*/

   public WirelessHelloWorld3Provider() {}

/*

* Initialize the provider

* Presentability of the provider to the desktop is based on the client type and content template retrieval

* @param n Component name

* @param s Session

* @exception ProviderException

*/

   public void init(String n, Session s) throws ProviderException {

      super.init(n, s);

      clientType = "";

      isGenericHTML = false;

      isPresentable = true;

      try {

         clientType = s.getProperty("ips.clientType");

         isGenericHTML = (Client.getInstance(clientType).

            getProperty("genericHTML")).equals("true");

      } catch (SessionException se) {

         throw new ProviderException("Unable to retrieve Session

            client type");

      } catch (ClientException ce) {}

/*

* Determine presentability.

* if (content template found), then the channel is presentable

* if genericHTML is true, then use parent methods for html markup and do not check for the template.

*/

   StringBuffer template = null;

   if (!isGenericHTML) {

      try {

         template = getTemplate(contentTemplate);

      } catch (ProviderException e) {

         isPresentable = false;

      }

      if (template == null) {

         isPresentable = false;

      }

   }

/*

* Get content for the client.

* @param m

* @return StringBuffer of the provider content.

* @exception ProviderException

*/

   public StringBuffer getContent(Map m) throws ProviderException {

      if (isGenericHTML) {

         return super.getContent(m);

      }

      StringBuffer content = getTemplate(contentTemplate);

      return content;

   }

/*

* Determine if the provider is editable

* @return boolean

*/

   public boolean isEditable() {

      if (isGenericHTML) {

         return super.isEditable();

      }

      return false;

   }

/*

* Determine if the provider is presentable

* @return boolean

*/

   public boolean isPresentable() {

      return isPresentable;

   }

}

Implementing the Client Data API

In order to access the Client Data and retrieve any Client Data for the device accessing the desktop, within the Provider, develop a method to:

1. Retrieve the clientType string value from the Session using the ips.clientType property.

2. Retrieve the client instance using the clientType value retrieved from the Session.

The client instance can be used to access the client's properties in the Client Data via the Client API. For more information, see "Client Data".

Initializing a Provider with the Init Method

The following is an example usage of the Client API that relies on the init method defined in the Provider API (PAPI).

com.iplanet.portalserver.providers

Class ProfileProviderAdapter
java.lang.Object

|

+--com.iplanet.portalserver.providers.ProviderAdapter

|

+--com.iplanet.portalserver.providers.ProfileProviderAdapter

init
public void init(java.lang.String n, Session s)

throws ProviderException

This initializes the provider. If additional initialization is required by the provider, this method can be overriden. However, the overriding init() call must always have super.init() as the first statement executed.

Parameters:
n - The unique indentifying name for this provider.

s - The user's session.

Example:
A following is an example implementation of this method in a non-wireless provider:

public void init(String n, Session s) throws ProviderException {

   super.init(n, s);

}

Using the Session API to Retrieve the Client Type

In order to make a provider client aware, retrieve the clientType from the Session. This clientType represents the type of client accessing the desktop. The clientType value is used as an index to retrieve appropriate Client Data objects which is subsequently used to access the client's file path and device specfic template files using the file lookup mechanism.

com.iplanet.portalserver.session

Class Session
java.lang.Object

|

+--com.iplanet.portalserver.session.Session

Use the getProperty() method to retrieve the clientType. Use the ips.clientType property name and retrieve the clientType value stored in the Session. The following example retrieves the clientType value within the Provider's init() method.

/*

* Gets the property stored in this session.

* @param name The property name.

* @return The property value in String format.

* @exception A SessionException is thrown if the session reached its maximum

* session time, or the session was destroyed, or there was an error during

* communication with session service.

*/

public String getProperty(String name) throws SessionException

Example:
private String clientType = null;

public void init(String n, Session s) throws ProviderException {

   super.init(n, s);

   clientType = "";

   try {

      clientType = s.getProperty("ips.clientType");

   } catch (SessionException se) {

      throw new ProviderException("Unable to retrieve Session

         client type");

   }

}

The provider can also be made to use the inherited PAPI getSession() method to retrieve the Session object. This object is set by the super.init(n, s). So, in the above example, replace:

clientType = s.getProperty("ips.clientType");

with:

clientType = getSession().getProperty("ips.clientType");

Using the Client API

After retrieving the clientType from the Session, use it to retrieve the client instance.

com.iplanet.portalserver.client

Class Client

java.lang.Object

|

+--java.util.Observable

|

+--com.iplanet.portalserver.client.Client

getInstance
public static Client getInstance(String clientType) throws ClientException { }

The following example includes the retrieval of the clientType from the Session.

private String clientType = null;

public void init(String n, Session s) throws ProviderException {

   super.init(n, s);

   clientType = "";

   Client clientObj = null;

   try {

      clientType = s.getProperty("ips.clientType");

      clientObj = Client.getInstance(clientType);

   } catch (SessionException se) {

      throw new ProviderException("Unable to retrieve Session

         client type");

   } catch (ClientException ce) { }

}

getProperty
After establishing the client instance, use the Client getProperty() method to retrieve data or properties from the Client Data objects.

public String getProperty(String name) throws ClientException { }

The following example includes the:

• Retrieval of the client type from the Session

• Retrieval of the Client instance

• Retrieval of the genericHTML property value from the Client Data and setting it to a boolean

  private String clientType = null;

  private boolean isGenericHTML = null;

  public void init(String n, Session s) throws ProviderException {

     super.init(n, s);   

     clientType = "";

     Client clientObj = null;

     isGenericHTML = false;

     try {

        clientType = s.getProperty("ips.clientType");

        clientObj = Client.getInstance(clientType);

        isGenericHTML = Boolean.valueOf(clientObj.

           getProperty("genericHTML")).booleanValue();

     } catch (SessionException se) {

        throw new ProviderException("Unable to retrieve Session

           client type");

     } catch (ClientException ce) { }

  }

getDefaultInstance
Use the Client API getDefaultInstance() method to retrieve the client instance corresponding to the default clientType.

public static Client getDefaultInstance() { }

Client clientObj = Client.getDefaultInstance();

getClientType
Use the Client API getClientType() method to retrieve the clientType string value for the current client instance.

public String getClientType() { }

The following example retrieves the default client instance and checks to see if the value of the variable clientType corresponds to the current client instance.

// the variable clientType has been assigned previously

if (Client.getDefaultInstance().getClientType().equals(clientType)) {

// do something

}

getAllInstances
Use the Client API getAllInstances() method to retrieve an iterator of Client Data objects for all known client types.

   Iterator knownClients = Client.getAllInstances();

   Client client = null;

   while (knownClients.hasNext()) {

      try {

         client = (Client)knownClients.next();

         String clientName = client.getProperty("clientType");

         String clientUA = client.getProperty("userAgent");

            // do something with the value

         System.out.println("Client=" + clientName);

         System.out.println("UserAgent=" + clientUA);

      } catch (ClientException ce) { }

   }

getPropertyNames
Use the Client API getPropertyNames() method to retrieve a set of property names for the Client instance

public Set getPropertyNames() { }

The following example retrieves all the client instances and all the property names for each client.

   Iterator knownClients = Client.getAllInstances();

   Client client = null;

   HashSet clientProps = null;

   while (knownClients.hasNext()) {

      try {

         client = (Client)knownClients.next();

         clientProps = new HashSet(client.getPropertyNames());

         String clientName = client.getProperty("clientType");

         for (Iterator it=clientProps.iterator(); it.hasNext();) {

            System.out.println("clientProps->" + clientName + "->"

               + it.next());

         }

      } catch (Exception e) { }

   }

profileChanged
public void profileChanged(ProfileEvent event) { }