portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Sean Taylor <da...@bluesunrise.com>
Subject Re: Struts-based portlet applications
Date Fri, 30 May 2003 06:50:24 GMT

On Thursday, May 29, 2003, at 05:56  AM, Mete Kural wrote:

>> However I think we could support Struts portlets as a special type of
>> portlet application, as a portlet container
>> Are you familiar with what a portlet application is?
> I kind of am. Basically as I understand, it's a group of portlets that 
> work together to provide application-level functionality, such as say 
> content management or CRM or an email client (Am I right?).

> So what are your ideas on what extensions to Struts are necessary in 
> order to build portlet applications with Struts as the framework? I 
> would think that an ActionPortlet class that wraps each portlet with 
> the JSR-168 Portlet interface may be necessary. Maybe 
> PortletRequestProcessor for event handling functionality at the 
> RequestProcessor layer?
Wrapping the Action Portlet with the Portlet interface doesn't sound 
I opted for the request processor, but ended disliking that approach 
too (for the entire portal server)

Interesting, that attached from IBM, thanks.
He didn't really go into the problems he had with two-phase processing 
of the portlet API.
I don't really have a solution for that one.
To me the best solution would be to have Struts as the portal server, 
since then we could make the specific call to the Struts action in the 
action phase, and then in the render phase process the JSP.
But in doing so, I found I was compromising the pureness of a portal 
application, and instead writing a bastardized portal server just to 
work with Struts.
I think you all should consider writing a Struts implementation of the 
Portlet API, or perhaps working with the Basic Portal guys on that.
Or working with Jetspeed, and try to support Struts as portlet 
Also, I don't see a good solution for writing your Struts application 
once, and running it as a servlet or a portlet.
In my mind they are different.
if you want to use your servlet only in a portlet with no portlet 
interaction then use an IFrame or WebPage portlet.

We also considered writing our aggregation with tiles, but again I 
didn't find tiles suitable for the task.
I believe one Jetspeed developer fancies writing an aggregation engine 
with tiles. Thats fine by me, as long as we don't corrupt the portal 

> There was an email in the Struts-user list a while ago about this 
> subject. It may be useful. I'm copying it here:
> From: "Jim Bonanno" <jim5@nc.rr.com>
> To: "Struts Users Mailing List"
> <struts-user@jakarta.apache.org>
> Subject: Re: Struts and Portlets
> Date: Wed, 26 Feb 2003 16:46:36 -0500
> I am glad to see the interest in supporting Struts
> applications in a Portal
> Server. I worked on adding support for Struts in
> WebSphere Portal, which
> added the ability to create Struts applications that
> can be deployed in
> WebSphere Portal. We encountered some relatively minor
> changes that could be
> made to the framework to help support Struts in a
> Portal Server, but there
> were other issues as well.  It was not clear how
> receptive the Struts
> community would be to some of these suggestions at the
> time but it sounds
> like the co-existence of Struts and JSR 168 may be an
> important one for the
> future. Some of the issues have already been raised
> like ForwardAction and
> the chaining of request processors. We had to package
> an implementation of a
> request processor, so that meant we also had to ship a
> Tiles request
> processor that inherited from ours.
> There were some general problems that we encountered
> in a Portal
> environment. The first was Struts depends on the
> servlet container to
> distinguish Struts actions from other requests, as it
> should. In a Portal
> server, the URLs use the servlet context of the
> configured Portal. The URL
> will have some additional information that the Portal
> server can use to
> determine which portlet the user is interacting with,
> and then some
> attributes for the portlet. We had to modify the tags
> that created URLs,
> like Form and Link, to create URLs to the Portal
> Server and then we added
> the Struts action, href, forward, etc as a request
> parameter. The portlet
> would then look at the parameter and determine whether
> to call the request
> processor because it was an action or include a jsp,
> for example. It would
> be a real convenience to create a hook in the tags to
> allow creating these
> custom URLs. We were able to subclass the link tags
> implementations and
> modify the tlds to use our version. That is fine, but
> I think Struts
> developers will want to create Struts applications
> that can be deployed in
> both a servlet and a portlet environment.
> Other changes that we needed dealt with the fact that
> in a Portal Server it
> is very easy to add a portlet to a page more than
> once. This could also be
> an issue when using Tiles as well. The problem that we
> encountered is the
> Struts form tag uses the name of the form bean as the
> form name. This name
> will not be unique if the same Struts application is
> added to the Portal
> page more than once. We had to namescope the name so
> it was unique, but that
> forced us to change the dynamic validation tags to
> also create unique names
> for the validation function.
> We also ran into issues with the response object. In
> Portal, the response
> object is committed by the time a portlet gets it, so
> we had to include
> instead of forward. The forward was convenient for
> many applications because
> you could forward to an action or a dynamic/static
> page. We recursively call
> the appropriate request processor for actions as
> needed and use an include
> if the URI was for a page. This also meant that
> pageContext.forward in a JSP
> would not function correctly, but that turned out not
> to be a big issue
> because of the logic forward tag which we could
> modify. This detail may be
> specific to my Portal Server.
> Portal also has two phase processing, as opposed to
> the servlet's one phase
> service method. There are some interesting design
> decisions that need to be
> made with how to map Struts processing with Portal's
> two phase processing.
> This is a feature in the JSR 168.
> The module support in Struts was very helpful to
> support the different modes
> in Portal. The portal mode could be used when
> selecting modules so the
> developer can create a Struts module for each of the
> portlet's mode, like
> view and edit. It was a nice application for Struts
> modules. Portlet modes
> are also part of the JSR.
> That's just an brief overview of some of the things we
> encountered, I don't
> want to bore this mailing list with all the details.

David Sean Taylor
Bluesunrise Software
+01 707 773-4646

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

View raw message