Comment regarding the <action-bean> idea, though it looks like an
enhancement like this might be put off until a later version.
I currently use Spring extensively to configure my Action objects
using the Spring DelegatingActionProxy. This works well on some
fronts, but configuration is a little painful to have to define all my
actions mappings in the struts-config.xml, and then define the actual
bean with its dependencies in action-servlet.xml. Since better
Spring/IoC container support is already on the Struts roadmap, it's
worth mentioning that the action-bean concept starts us down that
road.
In the near term, I think a concept like this would make it easier for
someone to build a better Spring add-on, where mappings and actions
*with their dependencies* could be defined in the same file. And I
think it goes without saying, that more complex dependencies such as
Chains could also be defined by the IoC container. Adding an
action-bean concept would allow the same actions class to have
different functionality not only by the ActionMapping passed in as an
argument, but also by having different dependencies injected.
This might not ever be part of struts - core, but it would be nice if
it could at least be supported with an add-on using XSL transforms:
<action path="/somePath" bean="myBean"
validate="false" name="myForm" >
<forward name="success" path=".theTile"/>
</action>
<action-bean id="myBean" class="com.xyz.actions.SomeAction">
<property name="businessDelegate"><ref bean="businessDelegate"/></property>
</action-bean>
--or--
<action-bean id="myBean2" class="org.apache.commons.chain.impl.ChainBase">
<constructor-arg><list>
<ref bean="specialValidationCommand"/>
<bean class="org.xyz.actions.commands.SaveCommand">
<property name="businessDelegate"><ref
bean="businessDelegate"/></property>
</bean>
</list></constructor-arg>
</action-bean>
/David Bowers
On Mon, 14 Feb 2005 16:43:56 -0600, Joe Germuska <[EMAIL PROTECTED]> wrote:
> Frank Z wrote:
> >>>This point made me think of something... What about the idea of adding the
> >>>concept of an <action-bean> in struts-config?
>
> At 12:11 PM -0800 2/14/05, Don Brown wrote:
> >The question is whether there will be a one-to-one mapping between
> >action-beans and action-mappings. If 90%+ of the time there will
> >be, this will needlessly complicate the config. I suppose, however,
> >if action mappings used wildcards heavily, this could come in handy,
> >course then I'd argue for wildcards in the action-beans to help
> >group them. :)
>
> I guess I figured on<action-bean> being an alternative to <action> in
> that it would have a "path" property. Maybe that's a bad idea, but
> it would be easy enough to throw another chain command in there which
> looked up the path against another store of expertise.
>
> Then again, it would presumably mean adding yet another property to
> ActionContext (getActionBean()?) That might be a bad path to head
> down.
>
> OK, Frank, sorry; you're not on to anything. ;^) Just kidding --
> good to think outside the box in all events.
>
> My inclination at this point is to treat the most complicated
> questions we're bumping up against as fertile ground for subprojects
> and contrib-type code until we really see what people want and what
> works. I don't think it is necessary to wrestle them all to the
> ground at once. Reviewing the latest roadmap, even some of the
> things I've already done or am planning on doing are a rew minor revs
> out. It's probably time to recalibrate the roadmap to our current
> interests and ideas.
>
> I've copied some of
> http://struts.apache.org/roadmap.html below; I left out the parts on
> which I didn't have direct comments.
>
> >Experimental Members
> >
> >ActionCommand - A Chain Command-like interface with one method...
> >ActionContext - A Chain Context that implements the logical Action class API.
> >ViewContext - A Chain Context that implements the logical "Velocity
> >Tools" API.
>
> At this time, I am convinced that explicitly passing ActionContext
> through Struts' chain is sufficiently better than having all the
> commands have to share info about where to find key context
> attributes and having them frequently cast to WebContext or
> ServletWebContext that I would take this out of "experimental" state.
>
> I also don't see how ViewContext would be terribly experimental,
> unless we immediately rewrote the taglib classes to use it. Even so,
> I'm not sure I believe it requires a long incubation period.
>
> After reading the section on ActionCommand, I could be persuaded to
> abandon my suggestion about changing Action in favor of presenting
> the ActionCommand interface, and "overloading" the <action> type
> attribute so that it might specify either an Action or an
> ActionCommand, or possibly adding a new attribute. Ted wrote it so
> that this level of "smarts" would be deferred until "Struts 1.5"
>
> >The Commons Chain WebContext we now pass around Struts Chain could
> >be called the "StrutsContext" to differentiate it from the
> >ActionContext and ViewContext.
>
> I'm not sure this is an issue any more. After trying to mix and
> match commands, I think it's worth stipulating that the
> ComposableRequestProcessor will always start the chain with an
> ActionContext.
>
> >1.4 considerations
> >
> >Consider adding catalog element. Depending on how the work goes with
> >the experimental ActionCommand interface, we might identifiy a need
> >to add a catalog element to the Struts configuration, to support
> >using a Chain of ActionCommands.
>
> This has already been done or doesn't matter, depending on how you
> look at it. There's direct support for looking up any command using
> the command/catalog attributes; on the other hand, if you want to
> specify an ActionCommand as the "type" for an ActionConfig, it seems
> like there's no clean way to support a catalog or any kind of lookup,
> nor a need, since the former solution exists.
>
> >1.5 considerations
> >
> >Based on our own work with the "experimental" members inroduced in
> >1.3.x, we might consider some other changes.
> >
> >Consider a "smart" action type. The idea is that a command in Struts
> >chain could look at the type indicated by the ActionMapping so both
> >Action classes and ActionCommand implementations are supported.
> >People could then mix-and-match Actions with ActionCommands (or even
> >chains of ActionCommands). We might even support placing an
> >ActionCommand interface on ActionForm, so people could skip having a
> >sepate Action or ActionCommand class. The ActionForm could do it all.
>
> As noted above, this seems like a necessity before 1.5 if you're
> going to actually use ActionCommand; I'm not quite sure how one would
> effectively designate ActionForm as a command; if one wants to have
> something "do it all," I don't think that thing should be called
> "ActionForm."
>
> Of course, this document has always just been a scratchpad of sorts,
> but perhaps now that a few of us are back to actively thinking about
> implementing future changes, we should revisit it and come up with
> one which reflects our intentions?
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
