portals-jetspeed-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mete Kural" <me...@touchtonecorp.com>
Subject Re: Struts-based portlet applications
Date Fri, 30 May 2003 07:39:01 GMT
Hi guys,
What I understand more and more is that the ways Struts needs to be tweaked in order to develop
a "portal server" is very different than the way Struts has to be tweaked in order to develop
"portlets". I am interested in doing both, but at this point I am more interested in how to
tweak Struts to develop portlets. Once the JSR-168 is public in a few weeks God willing, I
would like to make a proposal to the Struts developers to create a new folder under the /contrib
folder in the Struts CVS and get together a bunch of interested individuals to develop the
classes that are necessary to build JSR-168 portlets with Struts. I think there would be individuals
interested in several different organizations including open-source portal projects and portal
vendors. I know that Liferay open-source portal developer Brian is interested in this. Maybe
IBM will be interested as well since they have already provided a solution to build JSR-168
portlets with Struts in WebSphere Portal. I assume you, David and Scott, are interested. Do
you know others who are interested in such an effort?


---------- Original Message ----------------------------------
From: David Sean Taylor <david@bluesunrise.com>
Reply-To: "Jetspeed Developers List" <jetspeed-dev@jakarta.apache.org>
Date:  Thu, 29 May 2003 23:50:24 -0700

>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

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

View raw message