Thomas Boehme wrote:
>
> 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.
>
I don't know, use an implicit config access mechanism is OK but this makes
the interface very similar to servlet and does not highlight the fact that
every portlet will have "page location specific" configuration options which
make the life-cycle of a portlet a bit more complex that a servlet one.
I guess both scheme are OK, but should you document your choice in the API ;)
> > 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).
>
Good point
> > - 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'm not talking about "data XML markup" there, simply weel-formed XHTML, WML
or whatever.
I think in many portal will want to post-process a portlet output.
For example:
in XHTML case to merge all <link> and <script> elements in the <head>
of the aggregated document or to strip some "dangerous" tags.
in WML: the portal will want to retrieve all the <title> elements for building
a navigation stack before linking to the complete portlet content.
Using SAX events as the interface between portal and portlet makes this activity
both simple and efficient.
It's easy to connect an output stream to a SAX parser so there's no loss of
generality only the performance hit of a parser if you use tools that don't
output directly SAX events. Since I think portal will almost always need to
parse the portlet response, it's not an issue IMO.
> > - 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 saw the comments, just wanted to discuss it on the mailing-list
> > - 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).
>
Agreed, that cookie manipulation may have its use in a portlet, but I think
it should be located in an HttpPortletResponse rather that a generic
PortletResponse.
> 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.
>
Duh... I don't use JSP a lot, I should have checked the Servlet API before.
> > * 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.
>
How do they do this ? Different Accept headers for different requests ?
> > PortletConfig
> > =============
>
> > 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...
>
Did I mention that I did not read the complete API yet ? ;)
BTW, can you generate the index files for the Javadoc API, it'll make
it easier for browsing the stuff...
And what about putting a build directory with an ant build file for creating
the portlet API jar ?
--
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]
