--- Gary Affonso <[EMAIL PROTECTED]> wrote: > Ted Husted wrote: >> Meanwhile, in Struts 1 there is a "DispatchAction" >> that does much the same thing. From other >> discussions, I gather that "multiple actions per >> controller" is considered a Good Thing on platforms >> like Ruby on Rails.
It's really only a Good Thing in RoR because the framework and markup makes it easier to do it that way: it's a result of RoR's opinionation... Linking to a different action requires an additional parameter in the link tag "custom tag"; a conceptual equivalent might be an S2 link with a "namespace" attribute in addition to a configured "action" name. > But for what I do with it (fairly typical webapps) > one-action-class-per-action has served me very well. I don't think anybody's saying that it's a bad idea, but the framework does sort of "gently nudge" a developer in the multiple-methods-per-action-class (see below). > I have limited experience using webwork/s2 with AJAX > (I assume this is what you mean by "rich controls"). I think we're just talking about any type of control that requires some form of preparation on the server side; an Ajax control could be loaded by any action/method on page load. > Curiously, action!input is not a part of the > framework I'm familiarwith. Can you point me > to some docs that describe it? http://struts.apache.org/2.x/docs/action-configuration.html Look at the "Dynamic Method Invocation" section, 1/2-2/3 of the way down. > Again, not one *method*. That'd be crazy! That's what's being discussed, I'm pretty sure, but with an eye towards a different "prepare" cycle: the whole Preparable lifecycle makes more sense if there are multiple (request-handling) methods in an Action class. If there's only "execute" you don't gain very much by having the framework call prepare(), and I'd probably even argue it's less clear than calling it manually from execute(). If, OTOH, you have several methods that all require identical preparation then a prepare() in each method is a bit noisier than letting the framework call it. (This was just discussed on a current project and that seemed to be the general consensus, anyway, but for the most part I agree with it.) d. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
