Thread: [Webwork-devel] JSR 162: Portlet API
Brought to you by:
baldree,
rickardoberg
Menu
▾
▴
webwork-devel
|
From: DeSouza, E. <ede...@ja...> - 2002-01-09 19:41:54
|
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.=20 |
|
From: Rickard <ri...@mi...> - 2002-01-09 21:50:10
|
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 |
|
From: Rickard <ri...@mi...> - 2002-01-09 22:17:57
|
If you want to see my generally ticked off reply to this on TheServerSide, go here: http://www.theserverside.com/home/thread.jsp?thread_id=11106 Gotta do some more meditation now and calm down... *sigh*.. /R |
|
From: Philipp M. <me...@o-...> - 2002-01-10 11:44:57
|
On Wed, Jan 09, 2002 at 10:50:09PM +0100, Rickard wrote: > >Portlets rely on the portlet container infrastructure accessible via the= =20 > >Portlet API for functions like access to user profile information for=20 > >the current user, >=20 >=20 > WebWork Action *Aware interfaces. Nope, the aware interfaces won't give you a persistent storage of the users profile. Although one could pass the reference to user manager into the action via ApplicationAware. > >access to the window object that represents the window=20 > >in which the portlet is displayed,=20 >=20 > What does this mean? >=20 > >participation in the portal window=20 > >and action event model, access to web client information,=20 >=20 > WebWork Action *Aware interfaces. Rickard, I think you got this one wrong. I'm not sure but I think by accessing the "window object" the spec will give you a way to "roll-up", close and rearrange the portlets on the page (like my.netscape.com does). The event model will supplement this, I suppose by providing listeners for these "window"-events. > >inter-portlet=20 > >messaging=20 >=20 > ActionFactory.getAction() I doubt this already does the jobs ;-)) Although I don't know what inter-portlet-messaging would be good for. > >and a standard way of storing and retrieving=20 > >per-user/per-instance data persistently. >=20 > SessionAware.setSession(). Persistently! See above. Rickard, I don't see much benefits in this JSR either, but webwork alone won't do the job. Correct me if I'm wrong, it was you who did some portlet developing a xpedio IIRC. I really love webwork and I don't like this JSR but webwork is not the golden hammer. -billy. --=20 Philipp Meier o-matic GmbH Gesch=E4ftsf=FChrer Pfarrer-Wei=DF-Weg 16-18 Tel.: +49-(0)700-66284236 89077 Ulm |
|
From: Rickard <ri...@mi...> - 2002-01-10 11:58:49
|
Philipp Meier wrote: >>>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. >> > > Nope, the aware interfaces won't give you a persistent storage of the > users profile. What I meant was that the *Aware interface design allows you to plug these in easily. Although I'm not sure that's the best way to do that really. >>>participation in the portal window >>>and action event model, access to web client information, >>> >>WebWork Action *Aware interfaces. > > Rickard, I think you got this one wrong. I'm not sure but I think by > accessing the "window object" the spec will give you a way to "roll-up", > close and rearrange the portlets on the page (like my.netscape.com > does). The event model will supplement this, I suppose by providing > listeners for these "window"-events. Ok, I see, yes that is different. >>>and a standard way of storing and retrieving >>>per-user/per-instance data persistently. >>> >>SessionAware.setSession(). >> > > Persistently! See above. Depends on your implementation of session ;-) > Rickard, I don't see much benefits in this JSR either, but webwork > alone won't do the job. I agree, it won't. But to a large extent it does. > Correct me if I'm wrong, it was you who did some > portlet developing a xpedio IIRC. I developed portal stuff using WebWork, yes. > I really love webwork and I don't like > this JSR but webwork is not the golden hammer. I agree. /Rickard -- Rickard Öberg |
|
From: Philipp M. <me...@o-...> - 2002-01-10 12:28:41
|
On Thu, Jan 10, 2002 at 12:58:18PM +0100, Rickard wrote: > Philipp Meier wrote: >=20 > >>>Portlets rely on the portlet container infrastructure accessible via t= he=20 > >>>Portlet API for functions like access to user profile information for= =20 > >>>the current user, > >> > >>WebWork Action *Aware interfaces. > > > >Nope, the aware interfaces won't give you a persistent storage of the > >users profile.=20 >=20 > What I meant was that the *Aware interface design allows you to plug=20 > these in easily. Although I'm not sure that's the best way to do that=20 > really. Yes, ww make this easy. But that's the idea behind a framework, isn't it. The main work is the api that is made available via the *Aware interfaces. Making this api standard is not strictly wrong but the JSR does not concentrate on this layer (user, persistence, preferences...) either. -billy. --=20 Philipp Meier o-matic GmbH Gesch=E4ftsf=FChrer Pfarrer-Wei=DF-Weg 16-18 Tel.: +49-(0)700-66284236 89077 Ulm |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X