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 Thu, 29 May 2003 14:18:21 GMT
>WebSphere Portal comes with the ability to create struts base 
>portlets as of version 5.

Yes, that's great. It's good to see commercial support in this area. But I think it would
be better if the Struts project itself provided an open-source standard solution to build
Struts-based portlets and portlet applications. Maybe we can get together and make a case
to the Struts developers that the functionality to build Struts-based portlets and portlet
applications should be a default feature of a future release of Struts (like 1.2). David Taylor?
Scott Weaver?

Meanwhile until Struts 1.2 is released, the library of classes that extend Struts to provide
portlet-specific features would be provided under the /contrib folder of the Struts CVS.

Anyone interested in making this case to the Struts developers?


>-----Original Message-----
>From: Mete Kural [mailto:metek@touchtonecorp.com]
>Sent: Thursday, May 29, 2003 8:56 AM
>To: jetspeed-dev@jakarta.apache.org
>Cc: jetspeed-user@jakarta.apache.org
>Subject: Re: Struts-based portlet applications
>>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?
>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"
>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.
>---------- Original Message ----------------------------------
>From: David Sean Taylor <david@bluesunrise.com>
>Reply-To: "Jetspeed Users List" <jetspeed-user@jakarta.apache.org>
>Date:  Thu, 29 May 2003 11:15:37 -0700
>>On Thursday, May 29, 2003, at 03:13  AM, Mete Kural wrote:
>>> Hello again,
>>> With JSR-168 nearing the public draft stage, I was wondering if there
>>> is interest among the JetSpeed community to cooperate together with
>>> the Struts community in order to design and implement a library of
>>> standard classes that make it possible to build JSR-168 portlets based
>>> on Struts. Some ideas that I have are:
>>> - Designing and implementing an ActionPortlet class that implements
>>> the JSR-168 Portlet interface and extends ActionServlet
>>> - Designing and implementing a PortletRequestProcessor that provides
>>> an event handling model and adapts Struts applications to portlet
>>> applications
>>> I'm not an expert in the portlet field but I am just another fellow
>>> who would really love to see a standard library of classes for
>>> converting Struts applications into JSR-168 portlets that everybody
>>> can use instead of rolling their own. I hope JetSpeed experts and
>>> Struts experts will get interested in such a project. What do you guys
>>> think?
>>> Thanks,
>>> Mete
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>>Im interested.
>>I actually tried this a few months ago, wrote my own
>>PortletRequestProcessor and concluded that its the wrong place to
>>integrate Struts.
>>Struts is not meant to be a portal server, and it was leading to a
>>conformist style design.
>>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 think it would be best to move this discussion to jetspeed-dev, so
>>that other developers could be involved
>>David Sean Taylor
>>Bluesunrise Software
>>+01 707 773-4646
>>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: jetspeed-user-help@jakarta.apache.org
>To unsubscribe, e-mail: jetspeed-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: jetspeed-user-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