> After working on a portal project for a while with my team, I'd
> like to share some of our ideas.
>
> We see a big need for a standard Portlet API for Java that enables
> application developers to implement portlets that are independent
> of the underlying infrastructure. The Portlet API should provide
> standard interfaces, e.g. for tasks like accessing user info,
> storing/retrieving per-user per-portlet settings, accessing session
> info, accessing location info, etc. It has to provide good support
> for personalization of portlets. The Portlet API needs to be
> flexible enough to support different technologies (e.g.
> JSPs/servlets,
> XML/stylesheets) to generate portlet content.
>
> We'd like to evolve JetSpeed's portlet API in this direction and
> provide a portlet programmer's guide to give portlet developers a
> quick start.
I'm very much for defining a Portlet and Portlet Container API to
standardize portlets. Everybody already is "cloning" the term
Portlet. But what would be a huge service to the developer community at
large would be to have a standard API to allow portlets written for one
Portal to be easily switched to another.
I think the only basic requirement for the core API that I would like to
see is to have it independent of as many 3-rd party libraries as
possible. So we'd want to achieve independence from ECS, Turbine, etc. We
can always have classes further down the tree that use these libraries that
we can derive the Jetspeed-specific portlets from.
Count me in for help on this one!
-Mike
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
