Portal WebSphere Portal Class Notes Terms  Abstract by keralaguest


									                         WebSphere Portal Class Notes
   Abstract Portlet - Idea of a portlet, i.e. the source code.
   Concrete Portlet - Installed portlet, not on a page yet.
   Concrete Portlet Instance - Portlet on a page.

Misc Notes
   WebSphere Portal Architecture on page 15-4
   Use the jetspeed classes, MVC* classes are depreciated
   PortletAPI - the big picture on page 9-25
   Namespace Encoding done with response.encodeNamespace()
   URL encoding done with response.encodeURL()
   Portlet Caching on page 14-16
   Many resources are listed on page 21-4

Deployment Descriptors
web.xml - Web Application Deployment Descriptor
 init-param - Accessed through the PortletConfig object
 servelet-mapping/url-patturn is not used, but required

portlet.xml - Portlet Deployment Descriptor
 portlet id must be unique in the whole portal environment

Portlet Application
Standard layout from WSAD
                  (class packages)
                           html - .jsp files that create html output
                           wml - .jsp files that create wml output
                           tld directory - tld files
                           classes directory - Class files in correct package
                           lib directories - Extra libraries needed.
Portlet Class (set in portlet.xml)
Each portlet must implement a class that does all of its processing. Each portlet class will implement the
following methods to provide the functionality required.
        init() - Executes once at load time. The single instance created is shared with all users.
        initConcrete() - After construction but before portlet is accessed for the first time. This is per
        service() - called when portlet is required to render its contents. Dispatches to one of these
        methods based on the portlet mode.
         doView() - Normal viewing of the portlet.
         Typically ends with getPortletConfig().getContext().include(
             "/jsp/View.jsp", request, response);
         doEdit() - User options.
         doHelp() - Information on using the portlet.
         doConfigure() - Admin options.
        destroyConcrete() - Portlet taken out of service
        destroy() - Portlet terminated. Just before GC and finalize().

Portlet and Servlet Methods and Lifecycle
This table compares the methods of a servlet with those of a portal. At the same time, the lifecycle of a
portlet is also shown. All methods between and including beginPage() and endPage() are repeated until the
user logs out or the portlet is removed from the system.

    Servelets     Portlets             Lifecycle
    init()        init()               Portal initialized (once per portlet)
                  login()              User login (must implement PortletSessionListener)
                  beginPage()          User requests page (must implement PortletPageListener). This hook allows
                                       code to be added to the top of the page. Normally used for JavaScript code.
    service()     service()            Generate fragment for this portlet
      doGet()        doView()
    doPost()         doConfigure()
                                       Portlets are aggregated into one page.
                  endPage()            Allow portlet to add code to the end of the page (must implement
                  logout()             User logout (must implement PortletSessionListener)
    destroy()     destroyConcrete(     Cleanup when no longer needed.
Portlet Objects
The following objects are used in portal development. The first section is used to read and store data. The
second sections lists some objects that are used to understand what is going on inside the portal

    Object                          Write    Duration         Associate                         Page (Methods)
    PortletRequest                  Yes      User Request     User Request                      9-28
    PortletResponse                 Yes      User Request     User Request                      9-31
    PortletSession                  Yes      User Session     Concrete Portlet User Instance    9-34
    PortletConfig                   No       Persistent       Portlet                           10-10
    PortletContext                  No       Persistent       Portlet Application               10-14
    PortletSettings                 Yes      Persistent       Concrete Portlet                  10-17
                                                                                                config-param in
    PortletApplicationSettings      Yes      Persistent       Concrete Portlet Application      10-17
                                                                                                context-param in
    PortletData                     Yes      Persistent       Concrete Portlet Instance         10-17
    Object                          Description                                                 Page (Methods)
    Client                          Represents the users client application                     10-31
    PortletLog                      Access to the log files                                     10-34
    PortletException                Base of exception tree                                      10-36
    PortletURI                      Represents a URI to a specific portlet mode.                9-36

Four Modes and Three States
The four modes are Configure, Edit, View and Help. There are four methods in the portal class to provide
code for each mode.
The three states describe how Portal will display the portlet. These states are normal, maximized and

Portlet Listeners
These listeners may be implemented to add functionality to the portlet.

  Interface                                           Description                                             Page
  PortletSessionListener                              Initialize or cleanup PortletSession                    11-5
  PortletPageListener                                 Add to shared resources on the page                     11-7
  PortketTitleListener                                Provide a dynamic title for portlet                     11-10
  ActionListener                                      Allow portlet to receive PortletActions.                14-9
  WindowListener                                      Process changes to the portlet state                    14-15
  MessageListener                                     Accept messages from any portlet on the same page.      14-11
  PortletSettingsAttributesListener                   Receive changes to concrete portlet
  PortletApplicationSettingsAttributesListener        Receive changes to concrete portlet application
Events and Actions
There are two phases to processing. First is event processing then comes content generation processing. It
is guaranteed that trigger actions and window events occure before any messages are delivered and all
event processing will complete before content generation phase begins.

Currently, the API uses an interface (PortletAction, implemented by DefaultPortletAction) for a whole
object to use as an action. The next version will use only a string because that is all that is needed.

Normally, data generated in the action processing is needed in the content generation phase. It is a BP to
store the data in the request object. Do not use instance variables since the instance is shared for all users.

Message Events
Used to allow portlets to communicate with other portlets. A message may be to a single receiver or
broadcast to all portlets on the same page. Portlet must implement the MessageListener interface in order
to receive messages. A message may only be sent during the event processing phase.

Portlet Services (Custom, Vault Service and Collaboration)
Portlet services are discussed in unit 16. They provide a way to grant access to shared resources through a
developer created interface.

Unit 17 talks about a provided Portlet Service called Vault Service. Using segments and slots, a given user
may store any number of user/password combinations used to access services outside the portal

Unit 18 describes the collaboration components that allow multiple users to communicate through
Websphere Portal Server. Unit 19 describes the Lotus collaboration components.

Best Practices
This document describes the best practices discussed in class. The document at
http://www7b.boulder.ibm.com/wsdd/zones/portal/portlet/portletcodingguidelines.html (Portlet
Development Best Practices and Coding Guidelines) describes the full set of best practices.
 Portlets are Servelets so the same BPs apply.
      Portlets are multithreaded.
          No instance/class variables
          Static private final class variables are OK
          Shared resource access must be synchronized
          Don't sync whole method, just needed block
 MVC Still Applies
      Do not use JSPPortlet
      Extend PortletAdapter, AbstractPortlet or MVCportlet.
      Use the JSP only as the view.
 Know which data object to use
 Provide persistence services as PortalService
 Portlet UID must be unique

A - JSP Custom Tags
B - Customizing Portal (Themes for the page and Skins for the portlets)
C - Migration from WebSphere Portal 2.1 to 4.1

To top