On Mon, February 14, 2005 1:05 pm, Craig McClanahan said: > Since one can do this already (via ChainCommand), that doesn't strike > me as a strong argument to change the nature of Action.
I'm not seeing ChainCommand in the Commons Chain javadocs... am I looking in the wrong place? In either case, I assume you are referring to the duality of Command and Chain (i.e., Chain extends Command) allowing a person to insert a Chain in a Command "slot", so to speak. I'm not sure I see how this helps if Actions don't themselves implement Command. If they did, it's exactly what I was suggesting, just with the added ability of defining the "Action Command Sub-Chain", or whatever name you would apply to such a thing, outside chain-config, in struts-config specifically (a capability that may not exist now?) >> While I am usually a big fan of cutting down class count, this is one >> instance I wouldn't be happy doing so. I actually think the separation >> of Actions and ActionForms in Struts now is excellent, although I've >> never been thrilled with the name ActionForm, but that's not a major >> point :) This is actually one of the mistakes we made with the >> framework I was involved with... if we had thought of such a separation, >> I believe the end result would have been superior. > > One case this particular approach doesn't seem to cover as elegantly > is multiple buttons (in JSF parlance, "commands") that do different > things on the same data (save versus cancel button, page navigation > links, ...). If that would require multiple classes fo the same form, > I don't think that would be superior. This is I think were we get into the idea of that "method" attribute that myself and Don were suggesting... You could then still have a 1:1 mapping between a form bean and an Action, but each "command" the front-end could execute would be mapped to a specific method in the Action via the <action> mapping. There is of course nothing to stop someone from making multiple mappings to the same method, or having multiple "event handlers" in an Action, sharing form beans, etc. But, it sounds like such an idea is contrary to making Actions a Command in a chain, to the degree they might be mutually-exclusive, because the Command idea means the Actions have to implement the Command interface, which means they aren't actually POJOs any more, which means that one would always expect there to be an execute() method and that's what would be called. At that point, having the "method" attribute doesn't really buy you much that I can see. I suppose you could get both concepts intertwined by having a base Action like now who's execute method dispatches to the mapped method, but that sounds familiar :) And, it means the Actions aren't really POJOs anyway, so you still don't get your cake and eat it too :) Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
