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]
