Re: [Webwork-devel] JSR 162: Portlet API

[Dave B. <db...@in...>]

Did you actually look at the site. It looks like it's active to me. There's 
even some example sites online.

Dave


On Wednesday 09 January 2002 02:49 pm, you wrote:
> I¹ll be interested to see how this turns out, especially as it's based on
> JetSpeed which is a 'dead' Jakarta project (ie doesn't seem to have been
> updated in ages, I can't find a single production site running it). Also it
> used to have to have portlets coded in Java (as this seems to specify, it's
> a portlet API like the servlet API). Anyone remember the days of coding
> HTML in a servlet? ;)
>
> We'll wait and see I suppose.
>
> Back to your regularly scheduled WebWork programming!
>
> -mike
>
> On 9/1/02 2:41 PM, "DeSouza, Edwin" (ede...@ja...) penned the
>
> words:
> > For more info:
> > http://www.jcp.org/jsr/detail/162.jsp
> >
> > 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 application.
> >
> > 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
> > infrastructure.
> >
> > 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.
>
> Sent using the Entourage X Test Drive.
>
>
> _______________________________________________
> Webwork-devel mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/webwork-devel

-- 
Dave Bryson