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.
Jack
On Wed, 16 Mar 2005 08:02:32 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> 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
> which dispatch to the new signature.
>
> 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]
