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

[Rickard <ri...@mi...>]

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

-- 
Rickard Öberg