Thomas Schaeck (schaeck@de.ibm.com)
15. November 2000
The purpose of this document is to gather the requirements for the Portlet API to be provided by JetSpeed 2.
To contribute requirements, please send a brief description with a rationale to jetspeed-dev@jakarta.apache.org under the topic “Re: Portlet API Requirements”.
(Thomas Schaeck – schaeck@de.ibm.com )
The Portlet API should be a generic API that does not expose
JetSpeed intrinsics or components used by JetSpeed.
Rationale: This allows to implement the Portlet API on different bases, which is necessary to give the Portlet API the potential to become a standard.
(Thomas Schaeck – schaeck@de.ibm.com )
The Portlet API should clearly separate data that exists per
portal, per portlet, per user, per-user and per-portlet, per user session or
per request.
Rationale: This is required to implement the API and portlets that use it in a scalable and thread-safe way.
(Thomas Schaeck – schaeck@de.ibm.com )
The Portlet API should be similar to the Servlet API
Rationale: This will give all programmers who know servlets a quick start and lead to good acceptance of the API, increasing chances that it becomes a standard.
(Thomas Schaeck – schaeck@de.ibm.com )
The Portlet API should allow for definition of service interfaces
and for registration of services implementing particular service interfaces,
e.g.
Rationale: This allows for a stable API core that can be extended by services as required. Portals implementing the Portlet API can provide implementations for a subset of the services defined in the Portlet API.
(Thomas Schaeck – schaeck@de.ibm.com )
The Portlet API should be flexible enough to allow for rendering
using different technologies (e.g. JSPs, XML/XSL...) as well as different
mark-up (e.g. XML, WML, XHTML, HTML, VoiceXML, ...).
Rationale: This allows implementing portlets that can support various devices, either by doing final rendering or by producing XML that can be further processed.
(Thomas Schaeck – schaeck@de.ibm.com )
The Portlet API should provide abstract base classes for portlets.
Rationale: This allows for quick implementation of portlets by only overwriting the relevant methods.
(Raphael Luta)
The Portlet API should allow only well-formed XML compliant output
from the Portlet.
Rationale: this would guarantee that the portal can always post-process the portlet output if needed and would prevent a portlet from breaking the display with a non well-formed output.