>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? Mete > > >carlos > >-----Original Message----- >From: Mete Kural [mailto:[EMAIL PROTECTED] >Sent: Thursday, May 29, 2003 8:56 AM >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >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" <[EMAIL PROTECTED]> >To: "Struts Users Mailing List" ><[EMAIL PROTECTED]> >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 <[EMAIL PROTECTED]> >Reply-To: "Jetspeed Users List" <[EMAIL PROTECTED]> >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: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>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 >>[EMAIL PROTECTED] >>+01 707 773-4646 >> >> >> >> >>--------------------------------------------------------------------- >>To unsubscribe, e-mail: [EMAIL PROTECTED] >>For additional commands, e-mail: [EMAIL PROTECTED] >> >> > >--------------------------------------------------------------------- >To unsubscribe, e-mail: [EMAIL PROTECTED] >For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
