1. A few years back I was involved in the development of a framework where I was working (this was just around the time Struts was hitting the scene). We in fact did what Joe is talking about: abstracted away the fact that the controller classes (synonymous with Actions) were working in a servlet environment. We did this exactly as you are talking about: a context class that was passed around instead of request and response and all that jazz. Doing this in Struts will be a major boon in terms of more easily unit testing code and reusing parts of a system in other environments, i.e., it should be easier to slap a Swing interface over what was formerly a web front-end with the application itself working as it did before. I believe this change will be worth whatever pain it may cause in the short run, without any question in my mind. I suspect anyone that understands the benefits of this change in the user community will agree whole-heartedly, so while the concern about changing core Struts classes is perfectly valid, I personally would put it aside in this instance believing that any difficulty it causes is worth it.
2. Joe mentions that an Action starts to look like a Chains Command at this point interface-wise, but that an Action isn't intended to be used as part of a chain. This raises a question in my mind: why not? I admit to not being completely up on chains and all the changes you guys are making in the new Struts branch, although recently I've tried to play some catch-up :) So, why couldn't an Action be seen as a link in the complete "request handling" chain that Struts implements? I would think it very powerful to just look at an Action as another Command in a chain, whatever that chain may be, because then you could have a chain containing multiple Actions (which I actually thought was already on the list of new capabilities?), and not have to worry about dealing with anything other than Commands. In other words, removing the whole concept of an Action in favor of nothing but Commands really simplifies things a little bit: one less concept to think about. The argument against this I would think is backwards compatibility, but it sounds like Joe's approach deals with that already, so going the extra step or two and making Actions true Chain Commands makes sense to me.
-- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com
Don Brown wrote:
I don't mind sticking ActionContext everywhere as it is better than having the code rely directly on the servlet api, but since we are talking about modifying Action, why not get rid of this "must extend Action" stuff and make Action an interface? IMO, Struts core should depend on this new interface, say Actionable, where Action would be an implementation of this interface. Since the methods of Action like saveMessages have been moved to ActionContext, we can safely get rid of Action, a passing I won't soon be missing. :)
Don
Joe Germuska wrote:
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
--------------------------------------------------------------------- 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]
