Dear Wiki user, You have subscribed to a wiki page or wiki category on "Struts Wiki" for change notification.
The following page has been changed by MartinCooper: http://wiki.apache.org/struts/StrutsAction1Planning The comment on the change is: Typos. ------------------------------------------------------------------------------ There are three major issues with supporting JSR-168 (and probably a bunch of smaller ones as well): - * The framrwork 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 framework 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. - A strong goal should be that an application should be usable either as a webapp or as a portlet, with little (ideally no) changes. Therefore, we should build whatever it takes to support this into the standard framework distribution, which could then be used in both environments. + A strong goal should be that an application should be usable either as a webapp or as a portlet, with few (ideally no) changes. Therefore, we should build whatever it takes to support this into the standard framework distribution, which could then be used in both environments. == Relevant Proposals ==
