portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Santiago Gala <sg...@hisitech.com>
Subject Re: [VOTE] Portlet API, Results of the Chat
Date Fri, 02 Mar 2001 18:23:04 GMT
ingo schuster wrote:

 > Hi,
 > I posted the log of the PortletAPI chat some days ago. As there where no
 > responses, I assume that nothing is left to discuss with regard to the
 > issues we talked about in this chat. As we (at IBM) a very keen to start
 > implementing the new API, I'd like to vote about the point that we seem
 > to agree upon. We will of course have to vote on more details, however
 > as soon as the core design decisions are clear, we can at least start
 > with the implementation.
 > So I ask you to vote about following points:

Sorry for the delay.

 > Point 1 (output model):
 > The API will have streams in the base response API, SAX support in a
 > sub-interface; compliant portals must implement both interfaces.

+1. All I care about is that somebody is able to build a portlet engine that
can take care of SAX event stream so that it does not need reparsing until
the final "serialization/rendering".

 > Point 2 (content model):
 > Fragments are the prefered output model for portlets but the portal must
 > implement full documents support as the default.
 > The content model used by a portlet is defined in its portlet descriptor.

+1, I understand the issues brought by Raphaƫl. For completeness,
we should stick to this model, so that we can survive new formats/markups
without having to rush defining fragments model for each one.

 > 1. Should PortletRequest/PortletResponse have methods to access
 > ServletRequest/ServletResponse?

I would ask it as:
  should PortletRequest/PortletResponse IMPLEMENT 

I think we should not give the "true" objects to the portlet, just a facade.

 > 2. Should the session object be passed as separate object of the
 > Portlet.service() method?

-0. I think we should either go with a
service(request, response) model ---> Portlet implements servlet, 
PortletRequest implements ServletRequest
so that a servlet can be used as a portlet by the container, or a
getContent(data) model ---> RunData encapsulates all objects

 > 3. Should attributes in PortletRequest and PortletSession be prefixed by
 > the portlet container to separate portlet namespaces?

+1. A portlet should only view its own attributes. A portlet should not know
anything about the surrounding portlets.

 > 4. Should we stick with the attribute getters/setters from the Servlet
 > API or use the DynamicData object consistently across the relevant
 > objects (request, session, configuration, user, page)?

This goes up to my comment to (2). I think the crucial item is deciding
if we go for a overloaded (and with further semantics) "standard" 
servlet call, or if we have
a request model similar to the one in Turbine. Once we have this top 
level idea
clear, we can proceed. Mixing both in the model will be a mess.

I don't have a clear position on this one.
Having the first model allows for straight integration of existing 
servlets (at the cost
of more processing, cause they would deliver full documents).
Having the second model means a new API to define (based on the one in 
Turbine), and maybe
a cleaner interface.

 > 5. Do we want to stick with a pre-defined set of capabilities.
 > Preferably not, but if the names of capabilities are standardized, how
 > is the portlet going to find out whether a particular capability is
 > present?

We can have a mechanism similar to the one in TRAX:
the portlet can ask for an Iterator on capability names.
the portlet can ask for the value of a capability.
the container can throw an exception if it ignores the capability name.

This allows for futurer extensibililty. We define a minimum set of 
required and optional
capabilities supported in the version 1.0 of the spec.

 > 6. What should be the interface of the user?

I don't understand the question here. Which interface? who is the user?

View raw message