Browse Prior Art Database

Method to Persist Client State Information in a Portlet Disclosure Number: IPCOM000032974D
Original Publication Date: 2004-Nov-19
Included in the Prior Art Database: 2004-Nov-19
Document File: 1 page(s) / 59K

Publishing Venue



Disclosed is a method for persisting client state information in a portlet by direct transport of java objects via http request and response.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 1

Method to Persist Client State Information in a Portlet

In order for the portlet and applet to cooperate when multiple instances reside on a single HTML page, they must agree upon a 'token' or an 'id' to be used when identifying the form which will be used for communication. To obtain this portlet unique id, the Websphere Portal JSP tag <encodeNamespace> is used. Each portlet will generate a unique 'id' by passing a 'well-known' string to the <portalAPI:encodeNamespace> tag. The resulting string will be unique to that portlet instance. The portlet will pass this resulting id as a parameter to the applet. Further, in the portlet's jsp to be rendered, a form is defined with the name attribute set to a combination of this id and the form name. More succinctly, if the portlet passes the following value as a parameter to the applet:

<portletAPI:encodeNamespace name="xx " />

then it will also define a form with the name attribute set to

<portletAPI:encodeNamespace name="xxMyFormName " />

where 'xx' and 'MyFormName' are values agreed upon in advance by both the portlet and applet developers.

This form definition must reside within a <wps:portletEdit> tag (Reference 2.), and must have its Action attribute set to <wps:urlParent/>. This will cause the portlet to enter edit mode upon submission of the form. Also, the Portlet users must be given Edit permissions to the portlet.

Further, the portlet will have defined a javascript function which takes two parameters: a form name and a strin...