Raphael,
> * 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.
My favourite option is javax.portlet, but that's probably not becoming
true any time soon...
> 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().
Yep, absolutely! That's what the getAttribute() method is for. Some
configuration can be accessed with specific methods like getTitle()
or getDescription()
> 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)
That's what the persistence service is about. I am quite happy to connect
access to the psml attributes to some other place, if that's more
acceptable.
My personal wish would be to not further bload the service() method,
but rather attach the access to the session, for example.
> PortletResponse
> ===============
> - the createURI() method IMO should belong to PortletContext
Nope, because the URI generation is session dependent (for URL rewriting,
portlet IDs, etc). The Servlet API has encodeURI at the response too
(probably for similar reasons).
> - 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.
We are still in disagreement on the Portlet API on the mark-up level.
Of course, generating XML makes validation and verification a lot
easier, but I believe you are merely postponing the problem. Who is
validating the associated stylesheets? What should the Portlet API DTD
look like? As long as I haven't seen concrete examples, I am very
doubtful on the exact merits of this approach...
What do others think?
> - 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.
As I said in the Javadoc, there are two trains of thought here. Personally,
I agree with you, but others maybe wishing an "expert mode".
> - 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.
Agree. A cookie could just as well be handled through a generic attribute
storage mechanism (aka persistence service). We think, that connecting
to an HTTP source is one of the most likely things to happen in a portlet.
Since the portal acts towards those other content source on behalf of the
end user, the portal might have to store cookies that would normally be
stored in the user browser. Having those cookies handy for HTTP processing
seems a reasonable things to do.
Also, this way it would be possible to route cookies through to the user
browser for some portlets (configurable?) in case the user wants to
have the same viewing experience whether s/he goes through the portal
or directly to the content source (eg. web mail).
Again, what do other think?
> PortletRequest
> ==============
> * Same as above for getServletRequest() and getCookies(), getMethod()
well, same as above ;-)
> * I don't understand why there's both getAttributes and getParameters()
> what are the semantic/lifecycle differences ?
See Servlet API. Attributes are request-bound name/value pairs that can
be passed on to template mechanisms like JSPs. Parameters are the
name/value pairs from the URL of the request. These have to be filtered
for each portlet so that it doesn't "see" things it is not allowed to see.
> * the MediaType stuff should be found in the Client interface
Nope, because media types may change per-request. Some companies
are designing multi-modal devices that fire off requests with different
media-types within the same session. This behaviour cannot be captured
with the client interface only.
> * 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.
We hope so too. At the moment, we are trying to broaden the scope and
extend the windows events to action events. One possible action could
then be saving configuration.
> PortletConfig
> =============
> This interface is read-inly for the Portlet, right ?
Yes.
> 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 :)
Me too :-)
> 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...
Hmm, good point. We are currently going thru the window-manager stuff
and maybe we find another place for it. It should however be configurable
somehow, so that - for example - the ad portlet can be closed on one page
(premium content) but not on the other (free content)
> On a related note, I also think we should have a PortletEventListener
interface
> for registering callbacks to the close(), maximise(), minimize()...
events.
Huh? It's there already...
Thanks for taking the time!! We need more input like that. So, anyone
willing
to take Jetspeed to the next level is more than welcome to comment on the
Portlet API (see docs).
Cheers,
Thomas Boehme
--
--------------------------------------------------------------
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]
