Portlets are a part of Portal and assembled into a full fledged portal.

There is no Portal spec, they are vendor specific but the portlets are standardized so you should be able to run your portlets in any Portal.

Portal Page Elements

1)    Portlets

a.     title bar, and controls

b.     Portlet window

2)    Portal page (built up from portlets and static HTML)

The Portlets do not have to have title bar and controls like you see in Yahoo.

 

Portal app is part of a web app, webapp can have ‘normal’ Servlets and JSPs

Portlets deployed like Servlets

Web-inf/portlet.xml is the deployment descriptor.

Portlet can user Servlets and JSP’s to generate markup fragments or perform tasks

Portlets have access to other Servlet stuff.

 

Basics – Window States

1)    Normal

2)    Minimized

3)    Maximized

4)    Custom states

a.     Declared by portlet, only used if supported by Portal

b.     Example: HALF_PAGE, NARROW, FLOATING, WIDE… The portlet specifies these in the portlet.xml. If the Portal supports the custom stuff then they can be used, otherwise they are ignored.

Some/many of the state changes are triggered by the buttons in the top right of the portlet.

Portlet Mode

1)    view

2)    edit

3)    help

4)    custom modes

a.     declared by portelt, only usedif supported by Portal

b.     ‘standard’ custom modes suggested by spec: about, config, edit_defaults, preview, print

Portlet api has request and response things that are passed into the processAction (respond to action events) and render (generate markup) methods.

GenericPortlet overrides render and forwards to mode-sepcific methods (doView, doEdit, doHelp).

 

Lifecycle – each HTTP request only one Portlet can get ‘processAction’ only if the request is an Action URL and ‘trageted’ to the portlet. Render for each portlets, no guaranty of order, might do concurrently in threads, protlet returns content fragment. Portal assembles fragements into a web page.

 

Change things only happen in processAction method.  Portal decides when render happens, if one portlet is max’ed then none of the others will be shown.

 

Other API – mostly mirrors Servlet api’s. Except for the PortletPreferences which manages preferences for the portlet.

 

Example – hello world the portlet.xml has the title. Portal knows how to render the title bar from the descriptor, which buttons show up in the top right hand side.

 

 

More stuff.

 

URL’s to external stuff are fine and leave the Portal window to a new window.

URL’s to the portlets are different either action or render type.  The URL can have parameters and the parameters only go to the targeted Portlet.

 

Namespace Encoding

Portlets generate HTML that lives on a bigger page.

Requires name and identifiers to be named-spaced – unique to the portlet, avoid collisions, HTML id’s, JavaScript variables and functions

The render response class can tell you what your namespace is. You are expect to generate your JavaScript on the fly while rendering your Portlet.

 

Forms in a portlet

 

Forms should use POST, don’t use GET, use POST with the ActionURL and its parameters. The container generates the action URL and add ‘private’ parameters for these URL’s. These URLs go into the ‘action’ attribute for the FORM.

 

Preferences

 

Declared and defined in the deployment descriptor. Provides persistent customization of the portlets view or behavior. It is container specific how they persist. All the preferences are multi-valued and Strings. You have to take care of getting the types changed. You can only modify from the processAction method.  Store is an atomic method. May throw and exception if store is not possible (no user, no way to determine chance of success, no way to determine reason for failure).

 

HTTP Session Attributes – scoped to ‘PORTLET_SCOPE’ or ‘APPLICATION_SCOPE’

 

Any url you build needs to go through ‘encodeURL’.

 

Preferences are stored in a db but its vendor specific as to how they go to the db. I’m assuming there are places you can get in there and get the preferences and put them where you want them. The preferences are described in the deployment descriptor.

 

JSPs and Servlets

Allows protlet to externalize its rendering with the PortletRequestDispatcher. The JSP’s must render ‘fragments’. The JSP’s or Servlets can get at javax.portlet.config – the PortletConfig, javax.portlet… other stuff. There is a tag-lib for doing Portlet stuff in JSP’s. They allow you to get at the defined objects, build action and rnder url’s and get into the namespace.

 

JSP Portlet Pattern – portlet class contains performAction to (process forms, modify preference and session data, maintain state fo rmulti-page forms). Render method dispatch to JSPs (presentation markup, but JSP probably not generally reusable, must generate only fragements, jsp probably strongly tied to the portlet). JSP is hosted by WebApp, accessible from outside (rely on unpublished URL to hide it).

 

The example was krufty because of all the code in the JSP. I hope there is a better way to get the stuff into the JSP. Presenter asserts that the EL will make things better for JSP 2.0.  I need to play with it to form a better opinion.

 

Other Stuff

Your portlet does not get to decide what its type is going to be. In the render method you are told what the Portal wants.

 

There is no ‘declarative security’ for the Portlet and the security is weak. There is no Portal specification to say how things work. I.e. a banking portlet that needs ssl and a weather portlet that does not. It’s up to the Portal to determine what happens.

 

Portlets can be cached. The Portlet can specify how its cached.

 

WSRP – allows you to aggregate Portlets from other servers via a web-services interface. The two specs cooperated with each other.