WebSphere Portal comes with the ability to create struts base portlets as of version 5. I saw a demo
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]
