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: New API specification
Date Thu, 10 Jan 2002 11:08:42 GMT
Sandra Cann wrote:

>Snip
>
>>JetSpeed 2 will be a the sum of 3 things instead of 2:
>>
>>1) Portlet Container and Portlet Specs..
>>2) A Portlet Container Implementation, independent of any framework
>>
If we follow the original Portlet API specs it would be two, one for 
stream based aggregation and another one for SAXEvent stream 
aggregation. I don't know if we will push the scope of the JSR this far 
during the process.

>>
>>3) A Portal implementation, framework dependant..
>>
>
>I have a particular interest in seeing Jetspeed Portlet API and Struts/Tiles
>integration. I am delighted to see the direction of considering other
>frameworks to integrate with and particularly that of Struts. Using relative
>community sizes as a gauge of market size, the Struts community is more than
>twice the size of the Turbine list so by offering the choice of framework
>you can surely strengthen the acceptance of the Jetspeed project further.
>
>By integrating with Struts this will also make Jetspeed available for
>integration with the Expresso Framework and Jcorporate's collaborative
>applications - since as of version 4.0 Expresso is based on Struts. In your
>list of frameworks Expresso (www.jcorporate.com) was not mentioned and
>perhaps should be since it is has the largest framework community with more
>than 4300 developers on its listserv. By estimates the combined
>Expresso/Struts communities accounts for ~85% of OSS Java framework market.
>
The current jsp templating implementation uses taglibs for inclusion of 
Portlets. It will not be that difficult to have it use Struts and/or tiles.

What it is really important here is that we isolate carefully:

- A set of Portlet API and life cycle that can be built upon. (This is a 
rephrasing of 1 above)

The concern of this part is to specify the contracts between a Portlet 
Application builder and the portlet container, both in terms of API and 
services, and in term of life cycles.

- A basic implementation of the PSML aggregation, the registries, the 
aggregation engine. I work currently in a SAX Event container derivative 
of Jetspeed, which means I want two of these: one that passes 
bytestreams around, and another one that passes SAXContentHandlers 
around. (This is point 2 again in more concrete terms)

The concern of this part is to specify the contract between the Portal 
builder and the portlet container. I. E., how to specify pages that are 
aggregated from portlets and controls.

- For a given framework (struts/tiles, turbine, ... you name it) we need 
hooks that links the portlet life cycles and the container services 
(security, template resolution, psml resolution,...) with the framewok, 
to ease development of a pure (struts, turbine,...) portal. (This would 
be a set of point 3)

The concern here is how to link the portlet container in a given servlet 
environment, i.e. how to have templates that implement the different 
controls, controllers, portlets, etc. in different environments linked 
together, and how to bind requests to the container.

While we should have one reference container implementation, nothing 
stops us (us here mean the set of all communities) to have several 
portal implementations. One could be biased to use jsp taglibs, another 
to use a templating engine such as velocity (or PHP), another to use XML 
documents and XSLT transformations, etc.

If we do it right, the different communities will help to have a high 
quality API for portlet programming, and a high quality implementation 
of the aggregation language, and layout engine.




--
To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>


Mime
View raw message