(Seems this mail did not get delivered, I hope you don't receive it twice)
It's good to see such a positive reaction on my first note about the
need for a standard Portlet API and that such a live discussion started.
I guess we should go into more detail now. The figure below shows a
portal that provides a Portlet API for portlets to make them independent
of any specifics of the portal implementation (e.g. Turbine, ECS, Cocoon,
for JetSpeed or something else for other portals).
DB EJBs SOAP XML XML XML
| | | | | |
JSPs/Servlets Cocoon
| |
+-------+ +-------+
|Portlet| ... |Portlet|
+==========================================+
| Portlet API |
+==========================================+
+--------------------+ +---------------------+
DB --+ Persistence Service| | Location Service |
+--------------------+ +---------------------+
| Portal Framework |
+--------------------+ +---------------------+
LDAP-+ User Data Service | | Device Info Service |
| +--------------------+ +---------------------+
| +------------------------------------------+
| | Rendering Engine |
| | WML | HTML | VoiceXML | CHTML | ... | <- User PSML
| +------+------+----------+-------+---------+
| | Capability Detection/Rendering Selection |
| +------------------------------------------+
+---------| Authentication |
+------------------------------------------+
/\ ||
|| \/
Request Response
We envision a standard Portlet API similar to the Servlet API, providing
amongst others the following interfaces:
- Portlet is used by the framework to invoke the portlet. Every portlet
has to implement this interface.
- PortletRequest encapsulates the request to the portlet. It provides
access to parameters/attributes, locator and client information, etc.
- PortletResponse encapsulates the response to the portlet.
- PortletConfig provides the portlet with config info used by the portlet
as well as the framework to render the content.
- PortletContext provides the portlet with access to the framework's
services. The context allows the portlet to store/retrieve information
and access information that the portlet requires to render itself.
- UserProfile provides access to the user data.
- Client represents the user's client device. It provides methods to get
manufacturer, model, user agent and check for capabilities.
- Locator provides methods to determine the current location of a user's
device, e.g. longitude/latitude, country, state, city, ZIP code.
This is a preliminary, not-yet-complete list that we post to get early
feedback from the JetSpeed community. Please let us know your comments!
We also plan to submit a more detailled proposal soon.
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://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
