I believe now that we have a decent grounding to begin using the ActionContext as the request-scoped parameter throughout Struts - I think it can be applied to ActionForm and Action to hide dependencies on the Servlet API (and in ActionForm, to finally deprecate ActionErrors!)
Are there any reasons not to press ahead with changes like that?
I feel quite uncomfortable with committing significant changes to core classes like Action and ActionForm without some more review, so I'm going to be much more explicit about what I'm thinking. I could provide patches, or an alternate source build for download, but I think I can express the most important parts in email.
Here are the first two things I would do:
[1] in Action, deprecate:
public ActionForward execute(ActionMapping,ActionForm,HttpServletRequest,HttpServletResponse)
in favor of
public void execute(ActionContext)
The base implementation in Action would delegate to the old signature for as long as we saw fit to preserve it. It would take the "ActionForward" returned by the old signature and call context.setForwardConfig(ForwardConfig). Would it be worth returning anything from here? This is now so close to the interface for Command that I wonder if somehow it should be explicitly linked. However, it's not a command, in that it's not expected to be used by a commons chain. Is it worth relating them to each other?
[2] in ActionForm, deprecate: public ActionErrors validate(ActionMapping, HttpServletRequest) public void reset(ActionMapping, HttpServletRequest) in favor of public boolean validate(ActionContext) public void reset(ActionContext)
In both of these cases, the implementations would simply delegate to the deprecated methods. The new validate would return "true" if the delegated validate returned null, or a size 0 ActionErrors, otherwise"false"
This would allow us to finally deprecate ActionErrors, which would be nice.
As a consequence of doing this, we might be able to go through other parts of Struts and replace methods which explicitly depend on HttpServletRequest with ones which depend instead on ActionContext. The main value of this, in my mind, is eliminating the need to coordinate Attribute keys in requestScope and sessionScope in favor of encapsulating that inside the ActionContext implementation. Of course, it also helps eliminate dependencies on the Servlet API, which should make testing easier and might also help people who are interested in using Struts in Portlet, Web Services, or other slightly different environments.
What would be the correct approach to Struts' own subclasses of Action and ActionForm? I kind of assume we would need to not change them for a while since people who may have subclassed them may be depending on their implementations of the (proposedly) deprecated signatures?
Is this even a good idea?
Joe
--
Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com "Narrow minds are weapons made for mass destruction" -The Ex
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
