Hello Jetspeed developers, There is a new discussion on how to use Struts to build JSR-168 portlets in the struts-dev mailing list. I would like to encourage anyone here who is interested, to participate in this discussion in the struts-dev mailing list. I am copying Craig McClanahan's email to struts-dev regarding this topic below.
Thanks, Mete > Date: Wed, 13 Aug 2003 09:23:09 +0100 > From: Mete Kural <[EMAIL PROTECTED]> > Reply-To: Struts Developers List <[EMAIL PROTECTED]>, > [EMAIL PROTECTED] > To: Struts Developers List <[EMAIL PROTECTED]> > Subject: Struts for Portlets > > Hello Struts developers, > > I wanted to get your opinions on how Struts should be used as a portlet > framework. I think that it would be great if a portlet framework was > part of the standard Struts distribution in the near future. JSR-168 > which defines standard portlets will be finalized pretty soon (a > month?), although the specification draft is pretty much stable > hereafter. > > I have two main questions: > > 1) My first question is technical. How do you think portlet support > would be best added to Struts? Which classes should be extended? Are > there necessary changes at the core classes of Struts in order to > provide an efficient framework for building portlets? > Presuming we're talking about JSR-168 as the portlet framework, there are three major issues (and I'm sure a bunch of smaller ones as well): * Struts APIs assume servlet API objects (ServletContext, ServletRequest, ServletResponse), whereas JSR-168 talks about PortletContext, PortletRequest, and PortletResponse. We'd either need to change the calling sequence for Action.execute() -- problematic for backwards compatibility -- or fake it somehow in a portlet environment. * The lifecycle of a portlet request is actually divided into two chunks -- processing and then rendering. From a Struts perspective, that means making sure that the first part of the request processor pipeline need to happen in the "process" part, and the forwarding to the resulting page needs to happen in the "render" part. * Today, Struts owns the process of calculating URLs for pages and actions. Because it's in a webapp, it knows exactly what to do for the developer. However, in a portlet container it's actually the portal server that manages URLs, so a Struts-based portlet would need to interact with the portlet APIs for this purpose. > 2) Second question is about how a Struts-based or Struts-like portlet > framework should be distributed. Should it be part of the core Struts > distribution? Should there be two different Struts distributions within > the Struts project: "Struts for Webapps" and "Struts for Portlets"? Or > should it be a seperate Jakarta project? > Let me recast your question into a goal statement, and then let's see where that leads. I believe that we should aim for the following ideal state -- a Struts application shoud be usable either as a webapp or as a portlet, with little (ideally no) changes. Therefore, I believe that we'd build whatever it takes to support this into the standard Struts distribution, which would then be used in both environments. Assuming that we (the Struts developers) agree with this goal, we can start talking about making it actually happen. > I look forward to hearing your opinions. > > Thank you very much. > Mete > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
