I think the goal is that Struts should be both a servlet and portlet framework. So, yes, it would be a servlet/portlet framework. I'm not interested in portlets myself, but I do support the goal, for different reasons. I would like Struts to be a servlet/portlet/generic framework.
I would like Struts to become a controller framework with servlet, portlet, or whatever adaptors to process the incoming request. The processor could translate the request into a generic Context (a la Commons Chain), and pass that down to the rest of the framework.
Most of the Actions that most of us write now do not use a lot of web semantics. We pull properties out of form beans and pass them down to business classes. There are occasions when people do have to chase after cookies and whatnot, so we need to keep that door open. But what we do in these cases could often be built into the request processor and placed into the Context before calling the the Action. (Especially if the processor were more extensible, as proposed by the Commons Chain whiteboard code).
Ideally, there should be a form of the execute() signature without any reference to *Servlet* or Portlet* at all, along with other forms with those semantics if we need them. For example, the processor could call the signature with the web semantics, and that could turn around and call the generic one. (Just as we did with the process to execute forms.)
To choose whether to use a Servlet or Portlet Action (or even just a generic Action without any web semantics), the processor could use the factory pattern (as is done with the other config classes). To do it right, we'd have to migrate Action to an interface, with some default implementations. Of course, the default for 1.x would be the Servlet/HttpServlet Actions we use now. But it should plug right in.
I think the key is to pursue the new Request Processor implementation that Craig has suggested. Once that is in place, it would become very easy to plug in entirely different ways of processing the request. The use of the Context pattern opens many doors. And the way-cool way the default Chain Context supports JavaBean semantics can solve a number of documentation/type safety issues that the Context pattern can raise.
We've been steadily separating the Request Processor from the rest of the Controller. Given the Chain Processor, and David's ongoing refactorings, I think we'll be in a place where we can separate the deployment of the Struts configuration from the processing of the request.
This road ~could~ lead to alternate Struts front-ends that receive requests in different ways and just hand them off to the Request Processor. The Request Processor then becomes the actual Front Controller, and the servlet (or what have you) becomes a web adaptor sitting between the Controller and the Container.
The key is being able to "level the playing field" for the Request Processor, so that it can live outside a Servlet, Portlet, or whatever, environment, and rely on a Context to do the mainstay of its job. (As suggested by Craig's whiteboard code.)
I'm actually quite excited by the Commons Chain proposal. The paradigm is very close to what I'm using in my applications now. I'm about to start work on a new module on a paying project and hope to base the business layer on Commons Chain.
Brilliant stuff, really, and well worth a look see:
http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/
The whiteboard code in the Contrib folder is a real eye-opener:
http://cvs.apache.org/viewcvs/jakarta-struts/contrib/struts-chain/
-Ted.
Mete Kural wrote:
Struts 2.x series would be based on Servlet 2.4 / JSP 2.0, but that's it
Also for the Struts 2.x series, is there any inclination among the rest of the Struts developers to realize this goal statement that Craig mentioned:
"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."
Should Struts 2.x aim to be a portlet framework as well?
Mete
-- Ted Husted, Junit in Action - <http://www.manning.com/massol/>, Struts in Action - <http://husted.com/struts/book.html>, JSP Site Design - <http://www.amazon.com/exec/obidos/ISBN=1861005512>.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
