[EMAIL PROTECTED] wrote:
>
> (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.
>
Great, I don't have to write this anymore... :)
> 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
>
I completely agree with this drawing (if I read it correctly that is):
in your portlet API view, is the Portlet responsible for rendering its
output in the device format or is it handled by the portal framework ?
if the Portlet does not do the rendering, what does it output ?
> 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.
>
+1
> - PortletRequest encapsulates the request to the portlet. It provides
> access to parameters/attributes, locator and client information, etc.
>
+1
> - PortletResponse encapsulates the response to the portlet.
>
+1
> - PortletConfig provides the portlet with config info used by the portlet
> as well as the framework to render the content.
>
+1. But we may need to differentiate between static init parameters set the
portal administrator and instance-defined parameters (for example those set in
the current PSML).
If we start with this basic servlet-like API:
interface Portlet {
public void init( PortletConfig cfg );
public void service( PortletRequest rq, PortletResponse rs );
public void destroy();
}
If both admin-defined and user-defined parameters are set in PortletConfig
passed to the init() called, the portal engine needs as many portlet
instances running as there are different parameters value for a given portlet.
This doesn't scale very well for things like a RSSPortlet which takes its
URL as parameter...
If the user-defined parameters are given the PortletRequest we mix 2
different information source within the same object (user-defined
parameters are stored locally and may be trusted, form/query parameters
should not be trusted) and we may prevent the portlet from doing
some optimization of resource.
If the user-defined are accessible from the context and the context is
obtained by ServletConfig.getServletContext(), this is not thread-safe so we
still have one portlet instance/parameters set.
I thought about adding an additionnal setConfig() call in the Portlet API
thus leaving the portal implementation to use any instanciation model they
like (SingleThread or multi-thread) and make sure their implementation is
thread-safe.
Another way to do it is:
public void service( PortletRequest rq, PortletResponse rs, PortletContext ctx )
> - 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.
>
+1 with the caveat above: how does a Portlet get its PortletContext ?
> - 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.
>
I don't think hooks should exist in a generic portlet API to cater for this.
Too biased towards mobile devices and probably not available on every
implementation.
> 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.
>
There's one additional very important thing to consider : customization.
How does a portal know what parameters can be set for a given Portlet ?
How do we build an UI for customization ? Should we let the Portlet
give us a specific UI for handling its customization (in case of complex
Portlets ?).
For me, a Portlet is basically a Servlet and JavaBeans/EJB mix.
I would propose to handle customization by mandating Portlet to provide
a descriptor file describing its operational parameters. The portal should
provide a default UI implementation for entering parameters based on this
descriptor but the Portlet may register a specific Customizer for handling
complex needs.
Comments ?
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
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]
