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?
Thanks, Mete ---------- Original Message ---------------------------------- From: David Sean Taylor <[EMAIL PROTECTED]> Reply-To: "Jetspeed Developers List" <[EMAIL PROTECTED]> 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?). >yes > >> 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 >clean. >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 >applications >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 >design. > >> 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. >> > >-- >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]
