Joe Germuska wrote:
At 4:18 PM +0100 2/14/05, Wolfgang Gehner wrote:
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.
I can live with that, though personally I prefer features that are not hidden. As the 1.3 theme is "let it all hang out". And would have liked to get rid of the cryptic "type" attribute :-)
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.
Agree. It might be worth *stressing* somewhere in the doc that execute(Context) should be threadsafe. I've seen even Gurus (and myself in early days) committing the mortal sin of using instance variables in Action classes. There is even a Kepner-Tregoe case study on this.
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.)
You stress *either* Action or Command, so I suggest if someone does happen to create a HermaphroditeAction (extends Action and implements Command) Struts might call both hooks. In case of Command only, the user has to be smart enough to call context.setForwardConfig(context.getMapping().findForward("Success")); at some point.
I like Vic's "more chain, less struts config" Just wondered if we could actually create a chain-config clone of struts-config (at least the action part)? like use
<chain name="testChain" path="testAct" bean="testBean" beanClass="x.x.x" etc>,
<chain name="{1}Chain" path="{1}Act" bean="{1}Bean" beanClass="x.x.{1}" etc>,
to tell Struts about bean, forwards etc.? So we could avoid most struts-configs. I see that chain has no dtd for now. Or would that be considered polluting chain?
All I know is (Action)Form should *not* be a command, form bean is part of the V in MVC, and it should stay that way (at least per default. Nor combined with other classes. How about a viewcontrollingmodel, or modelcontrollingview...
I feel pretty good about this.
Didn't get many reactions on the ActionForm side -- any concerns about changes to it?
Joe
At the end, simpler, clearer, straightforwarder is better. As Vic said: "Struts is like a kindergarden, here you put your shoes, there your coat, and the books are over there, and now we know where to find things."
Putting everything in one place we call the "EggLayingWoolMilkPig" where I come from. In programming terms, I call this the "ApplicationFacade Pattern". :-)
Wolfgang Gehner
