add this shortcut:
<action path="/testAct" commandClass="com.mD.test.NewCmd" name="testBean" scope="session" validate="false">
While type="a.b.c.xxxAction" goes to "classic" Action.
I've been thinking about something like this; I was even thinking about whether we ought to simply let the value specified for "type" be interpreted more loosely. I was thinking possibly about changing "CreateAction" (which is where the ActionConfig is used to instantiate a processing object) behave more flexibly: instantiate *whatever* is indicated in "type"; if it's an action, call context.setAction(x); if it's a chain command, call context.setCommand(x). Later commands can recognize the presence of either of these in the context and execute it accordingly.
At 4:18 PM +0100 2/14/05, Wolfgang Gehner wrote:
This is just reminding me that Action must be threadsafe,
http://struts.apache.org/userGuide/building_controller.html
i.e. no instance variables.
Not the same for chain commands, I guess. Someone will ask the question of performance hit through using chain instead of action (now I do). I guess I could make command.execute static... Anyone want to run a load test?
Chain commands should also be threadsafe; they are used in an equivalent process where one instance's execute method might be called from any number of threads. I see no reason an alternate model even needs to exist, since the context can carry any state information necessary.
However, one could modify the "CreateAction" class so that it didn't cache actions in application scope, effectively causing them to be created for each ActionContext, and thus permitting them to be written with instance variables.
At 3:56 PM +0100 2/14/05, Wolfgang Gehner wrote:
Psychologically, I would not deprecate the good old execute(1,2,3,4) yet. Else Struts 1.3 will make all the millions of existing Struts apps look old (which is the same as "bad" in the era of Nip/Tuck). "If people want to code the old way, let them" (quote of my lead developer), esp. on something as established as Struts. Bad enough Shale makes people mistakenly think that good old Struts is being abandoned. Deprecating tested methods won't help much imo.
Well, although I'm not sure I agree, this is exactly the kind of discussion I wanted to see before I committed anything, and I think keeping the costs of upgrading psychologically low is worth keeping in mind.
Perhaps, then, we simply leave ol' Action to go out to pasture, and simply make it easier to indicate that you want to use a command by using the flexible interpretation of "type" i outlined above. We could write an "ActionCommand" class which simply passed "execute(Context)" to "execute(ActionContext)", for those who wanted it (like I kind of do for all of our existing commands), but since ActionContext extends Context, the only requirement would be that "type" refer to an instance of *either* Action*or* Command. We could leave in the catalog/command syntax for people who have reason to specify by name instead of by class name (particularly when they want to use a chain instead of a single command.)
I feel pretty good about this.
Didn't get many reactions on the ActionForm side -- any concerns about changes to it?
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]
