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

[Mike Cannon-B. <mi...@at...>]

Couldn't have put it much better myself. AFAIK JetSpeed has more of a
presentation focus than webwork (despite all Rickards * = Actions ;)) - it's
more like a badly written webwork + sitemesh combination app.

I looked again at the sample sites, 2 seem to be running the example app
built from CVS, one is actually using JetSpeed but mainly as an aggregation
tool for RSS feeds (which the webwork example does nicely too), and the
other example app is actually now running slashcode (www.slashcode.com - the
perl source behind slashdot).

There was some mention of a portal framework built ontop of webwork a while
back - perhaps this would make a good sample app?

-mike

On 9/1/02 4:50 PM, "Rickard" (ri...@mi...) penned the
words:

> Interesting. Thanks for the link! Comments inline.
> 
> DeSouza, Edwin wrote:
> 
>> 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.
> 
> 
> Sounds like WebWork actions.
> 
> 
>> 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.
> 
> 
> Still sounds like WebWork actions, with a touch of JSP taglibs to
> simplify things (e.g. the "url" tag).
> 
> 
>> Portlets rely on the portlet container infrastructure accessible via the
>> Portlet API for functions like access to user profile information for
>> the current user,
> 
> 
> WebWork Action *Aware interfaces.
> 
>> access to the window object that represents the window
>> in which the portlet is displayed,
> 
> 
> What does this mean?
> 
>> participation in the portal window
>> and action event model, access to web client information,
> 
> 
> WebWork Action *Aware interfaces.
> 
>> inter-portlet 
>> messaging 
> 
> 
> ActionFactory.getAction()
> 
>> and a standard way of storing and retrieving
>> per-user/per-instance data persistently.
> 
> 
> SessionAware.setSession().
> 
>> 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, 
> 
> 
> I wonder how those tags will compare with those developed under the
> Standard Taglib JSR.
> 
>> cleanly separating portlets from the surrounding
>> infrastructure so that portlets can run on different portal servers like
>> servlets can run on different application servers.
> 
> 
> Right. Just like WebWork actions can run in any servlet engine then. (or
> Struts or whatever).
> 
> 
>> The Portlet API specification shall evolve from the portlet concept as
>> developed in the Apache JetSpeed Open Source project.
> 
> 
> What an absolutely terrible idea since JetSpeed is badly mis-designed :-(
> 
>> 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.
> 
> 
> Right, so making Portlets extensions of Servlets doesn't really work.
> 
> 
>> 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.
> 
> 
> As is the case with WebWork, Struts, Maverick or whatever web framework
> you fancy.
> 
> 
>> 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.
> 
> Like our ClientDispatcher stuff then.
> 
> Overall, this sounds like an terrible idea. Basing a JSR on a specific
> product like this, which happens to be generally bad, sounds stupid.
> IMHO it is really better to have all of the frameworks that we have
> today. I don't see the value in what they are proposing *as a spec*. In
> four years perhaps, but not now.
> 
> /Rickard


Sent using the Entourage X Test Drive.