portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ingo schuster <ingo.apa...@web.de>
Subject Re: Portlet API - call to vote
Date Wed, 02 Jan 2002 09:13:32 GMT
Hi All,

best wishes to all of you, a happy new year!
Sorry for not participating for such a long time - I simply didn't find 
enough time to contribute to the jetspeed development in a sensible way. 
Hope this gets better this year... :-\

I think the JSR question is an important decision and as an "IBMer", I'll 
obviousely support the proposal... ;-)

At 06:43 12/29/01, David Sean Taylor wrote:
>Hi All,
>With the coming of the new year, I am looking forward to moving on to
>The first subject to discuss is whether the Jetspeed developers would like
>to support the Portlet API standards effort, and participate in the JCP
>expert group.
>I'd like to then call for a vote on:
>(1) Does the Jetspeed Community support the Portlet API Standard being
>defined in the Java Community Process (so that it will be standardized in
>the context of J2EE) This implies that we will base Jetspeed-2 on the new
>proposed standard.


>(2) If yes, does the Jetspeed Community want to participate by sending
>Jetspeed Developer(s) to the Portlet API JSR Expert Group ?


I like Davids idea of having a representative who votes according to the 
outcome of our voting process!
 > The committer(s) who are expert members of the group will vote.
 > However, we could vote in the usual apache way (+1 -1) on the list, and
 > then have our representatives make the final vote in the JCP group.


>The JSR is yet to appear at jcp.org.
>I've included below Thomas's description (again) of the Portlet API
>specification, which contains much of the same text as sent to the JCP.
>The Portlet API specification defines an API for web application components
>that interact with and can be aggregated in web applications like portals.
>We refer to these components as portlets in the remainder of this text.
>Portlets are web components like servlets, but have additional, special
>properties that allow them to easily plug into and run in enclosing web
>applications like portals. Portlets are designed to be aggregatable in the
>larger context of composite pages, e.g. multiple instances of the same
>portlet parameterized with different per-user, per-instance portlet data
>can coexist on the same portal page. Usually, many portlets are invoked in
>the course of handling a single request to aggregate their respective
>produced markup fragments in a page of markup. The markup fragments
>generated by portlets often need to contain links to trigger actions in the
>portlet, therefore URL-rewriting methods are required that allow portlets
>to transparently create links within the markup fragments they output,
>without needing to know how URLs are structured in the particular web
>Portlets rely on the portlet container infrastructure accessible via the
>Portlet API for functions like access to user profile information for the
>current user, access to the window object that represents the window in
>which the portlet is displayed, participation in the portal window and
>action event model, access to web client information, inter-portlet
>messaging and a standard way of storing and retrieving
>per-user/per-instance data persistently.
>The Portlet API provides standard interfaces for the functions mentioned
>above. The Portlet API extends the servlet programming model and defines a
>common base class and interfaces for portlets and tags for JSPs called by
>portlets, cleanly separating portlets from the surrounding infrastructure
>so that portlets can run on different portal servers like servlets can run
>on different application servers.
>The Portlet API specification shall evolve from the portlet concept as
>developed in the Apache JetSpeed Open Source project. In many aspects, the
>Portlet API is an extension of the Servlet API, defining additional
>interfaces for portlet-specific functionality. In some other aspects, it
>restricts use of functions provided by the Servlet API to the subset that
>makes sense for portlets just producing aggregatable markup fragments and
>not having ownership of the entire page that displays them. For example,
>unlike servlets, portlets may not send errors or redirects as a response,
>this may only be done by the application that invokes and aggregates the
>portlets into a larger page.
>Portlets can be grouped in Portlet Applications. Portlets in one portlet
>application can exchange messages via the Portlet API. Portlet Applications
>are packaged, distributed and deployed using WAR files that include
>portlet-related meta-information, utilizing existing Servlet
>The Portlet API shall be compatible with the Remote Portlet Web Services
>concept in the sense that portlets written to the Portlet API can act as
>local proxies in a portal server for remote portlet web services located on
>other servers and portlets written to the Portlet API can be wrapped into
>remote portlet web services.
>To unsubscribe, e-mail:   <mailto:jetspeed-dev-unsubscribe@jakarta.apache.org>
>For additional commands, e-mail: <mailto:jetspeed-dev-help@jakarta.apache.org>

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

View raw message