This is where the present options (making the request processor composable and providing a basis for business logic) goes "nuts" and begins to toss the entire idea of Struts out the window. I definitly don't think that this is a good idea.
This is a huge move which has nothing to do with the composable request processor. I would suggest that this is precipitious.
What is your antecedent for "this"? Having an ActionCommand interface? Using an IoC container as an ActionFactory? Having a ThreadLocal store the current ActionContext?
Jack
On Wed, 16 Mar 2005 08:02:32 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:> which dispatch to the new signature.Alright! Well, I succeeded in generating some discussion, which is fantastic -- thanks to everyone who weighed in.
At 8:48 PM -0800 3/15/05, Martin Cooper wrote: >I'm not sure I see the reasoning / benefit of POJOs as Actions.
Well, here's my specific case. As we design this new application, I would like to use a pattern which I used in a previous app, but update it to work better with Struts 1.3. This pattern relates to the ActionContext, and basically, I intend to provide a custom implementation of ActionContext which has typesafe accessors for my application's critical request- and session-scoped properties (like a "user" and some other more domain specific stuff you don't care about).
So the last thing I want to do is implement subclasses of Action which get "mapping, form, request, response" and have no handle on my CustomActionContext. I want that thing front-and-center. If we manage to get a "getCurrentActionContext" method as discussed elsewhere, then I could get at that, and I could write traditional Action classes which simply ignored the mapping/form/request/response arguments and called up the current ActionContext.
At 9:23 AM +0100 3/16/05, Manfred Wolff wrote: >I think there is on little design problem in struts that depends on >the history: It would be much better, if Action is an interface. So >you would have all possibilites to use POJOs, it must only implement >the new Action-Interface. Secondly it were also much better, when >the execute-Method must only take a context interface. So you have >more flexibility and you have no servlet-things at the paramater >signature: > >public interface Action { > void execute(Context context); >} > >where Context is also an interface.
And in fact, as of last night, we're 75% of the way there. I defined the ActionCommand interface, which looks more like a chain Command than your example above, but is effectively equivalent.
I stopped short of making Action implement ActionCommand with an implementation that simply pulled things out of the ActionContext, passed them to the current execute(..) method, and placed the returned ActionForward in the context. Actually, I stopped short of committing it. I wrote it, and I thought about committing it, but I remember that we bumped up against some uncertainties and hesitancies last time I brought it up, so I thought I'd wait to see what happened on this thread...
Still, if we did the above and then changed ExecuteAction to simply call action.execute(ActionContext), it would make a lot of things more straightforward. It would eliminate the critical need for a getCurrentActionContext() method (and the question about where to put that method), and it might maintain some of the clarity that other committers noted as valuable earlier in this thread.
I wasn't quite sure what to do with the dispatch classes, since some people would want behavior which uses the traditional method signature, while I want to dispatch using the new signature. I think I'd leave them as they are and direct people to parallel classes
So, if I have a way to get my own ActionContext into my actions, then I'm less concerned about the current mechanism for specifying a custom ActionContext. I'd want to hear more on the ActionContextFactory threads before making any changes there...
Just additionally:
At 5:52 AM +0000 3/16/05, Niall Pemberton wrote:
>One scenario would be to have an IoC container create a
>POJO and inject whatever resources it needed, populate it from the form data
>and execute a method.
In fact, I have become quite enthusiastic about the possibility of using Spring for just this, and I like its model of intervening in the "create action" process with a lookup to see if there's a Spring "bean" with the same name as the request path. This bean is expected to be an action, and Spring delivers a fresh instance to you with its collaborators already wired. That is, Spring already knows about my "userManager" and rather than having to have my action know where to find it in the soup of scopes, it's just there.
I think this should make Action classes which are much easier to unit test without worrying that they are somehow getting entangled in more things than you can reasonably mock out in a non-servlet-container environment.
I wrote a CreateAction subclass which emulates the behavior of the DelegatingRequestProcessor and will be seeing just how that works in practice real soon now.
http://www.springframework.org/docs/api/org/springframework/web/struts/package-summary.html
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]
-- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--
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]
