We had very good discussions about the Portlet API for
future versions of JetSpeed. I think that we should start
to compose a requirements list to gather the requirements
for the API, listing a description and rationale for each
requirement.
I volunteer to put together a Portlet API Requirements
List that we can put on the web site. Please post your
requirements to the JetSpeed list with the topic
"Portlet API Requirements", and I'll include them in the
document.
I'm looking forward to your input :)
--------------------------------------------------------
(my input)
- 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.
- 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.
- The Portlet API should be similar to the Servlet API
- Portlet similar to Servlet
- PortletConfig similar to ServletConfig
- PortletContext similar to ServletContext
- PortletRequest/Response similar to ServletRequest/
Response
- ...
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.
- The Portlet API should allow for definition of service
interfaces and for registration of services implementing
particular service interfaces, e.g.
- User info (for getting user info like name, address, age...)
- Persistence (for storing per-user, per-portlet settings)
- Location (for obtaining the user's location)
- Personalization (for storing/getting personalization info)
- Data (access to databases, schema-to-object mappings)
- Content (access to syndicated content)
- Cache (access to URLs via caches)
- ...
Rationale: This allows to have 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.
- 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 to implement portlets that can
support various devices, either by doing final rendering
or by producing XML that can be further processed.
- The Portlet API should provide abstract base classes for
portlets.
Rationale: This allows for quick implementation of portlets
by only overwriting the relevant methods.
Best regards,
Thomas
Thomas Schaeck
IBM Pervasive Computing Division
Phone: +49-(0)7031-16-3479 e-mail: [EMAIL PROTECTED]
Address: IBM Deutschland Entwicklung GmbH,
Schoenaicher Str. 220, 71032 Boeblingen, Germany
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
