I've finally had the time to look at the proposed new Portlet API
(/docs/proposals/portletAPI/ in CVS) and while I did not try to
compile it yet, I have some initial comments to the proposed
interface :
* first very minor point: I think the package should be org.apache.portal
to stress the fact that it may be used outside of Jetspeed.
Hereafter, I comment some specific interfaces without any specific
order except the one on my notebook... ;)
Portlet:
========
Implicit to the Portlet description is that the Portlet lifecycle is
servlet like (ie the portlet may serve many service calls during its
life but init() and destroy() are only called once and a portlet may
service requests for different users and document contexts).
In such a model, the PortletConfig passed to the init() method should
give access to the "registry" parameters only since they are the only
one known at init().
Also, the "psml" parameters can't be currently passed to the portlet in
its service method, so I think we add a third parameter to service():
service(PortletRequest,PortletResponse,PortletRunContext)
PortletResponse
===============
- the createURI() method IMO should belong to PortletContext
- I think the PortletResponse should provide SAX handler methods
for direct output of SAX events to the portlet container.
The getWriter() method may be kept but portlet container should
probably use it to feed a parser that outputs SAX event...
This is the only way I see to enforce well-formed XML output
at portal level, thus making sure that a portlet response may be
cheaply post-processed.
- I don't like giving access to a ServletResponse. A Portlet may possibly
be used in a non-servlet environment. The Portlet interface should not
be dependent on an external interface like Servlet.
- I don't like the setCookie() call as it has an heavy HTTP bias and thus
should only appear in a HttpPortletResponse subinterface. In the generic
interface, I think that if PortletSession allows the portlet to specify
persistence options for a value, it would replace the functionality of
cookies but leave the choice of the persistence mechanism used to
the Portal.
PortletRequest
==============
* Same as above for getServletRequest() and getCookies(), getMethod()
* I don't understand why there's both getAttributes and getParameters()
what are the semantic/lifecycle differences ?
* the MediaType stuff should be found in the Client interface
* About the Request.Type: I understand that this is supposed to document
the actual "methods" recognized by the portlet. Is there really a difference
between the ADMIN and EDIT method, (both changes the persistent state of the
Portlet and differ only by user privileges) ?
I also sincerly hope there is a better way to express the save state than
using an 'EDIT_SAVE' method but I can't see one right now.
PortletConfig
=============
This interface is read-inly for the Portlet, right ?
This the portlet implementation proper can't specify which Locale or media-type
it supports and this must be described by an external descriptor... yes,
I like that :)
However I don't think the canBeMaximized(), etc... should be present in
this interface but probably in windo-manager related interface which can or
cannot be implemented by the portlet...
On a related note, I also think we should have a PortletEventListener interface
for registering callbacks to the close(), maximise(), minimize()... events.
OK, enough for this time. I'll tackle other points later, for now I'm tired.
--
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://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
