On 1/23/06, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > Michael Jouravlev wrote: > > ;-) (Frank, any particular reason for not liking dispatching actions?) > > It's off-topic for this discussion I think, so I'll give you a quick > answer (as quick as I'm capable of at least!), and if you'd like to > discuss it more, feel free to eMail me or start a new thread somewhere...
I don't think its offtopic, on contrary I think it is quite relevant. I will continue here, if you don't mind ;-) Fixing cancel button via DispatchAction is a win-win that keeps standard actions compatible with current implementation and encourages to use dispatch action. > First, I prefer looking at 10 different classes with 10 lines of code a > piece than one with 100 lines of code. I care more about number of lines in a method than in a class. Dispatching action can have what? 2, 3, 5 methods, not a big deal. All quite observable and belonging to same logical entity. Remember, that Action and ActionForm were meant to be together, they were separated on birth by evil father ;-)) They are one thing in WebWork. Thus, Action/ActionForm is a classic object in terms of OOP, while event handlers expose the behavior. Seems pretty logical for me. > In addition, I think it makes working in teams a little easier... this > tends to be true any time you make things more granular. You can dole > out tasks in a more fine-grained way. Don't think so. If someone works on a logical entity, let him have it all. So no difference for me, to lock one dispatch action or five regular actions. > I think there is less chance of breaking something inadvertently when > you have to make a change with a regular Action than a DispatchAction > (although I admit I have no evidence to support this one at all!) No evidence, no case ;) > Also, I prefer to think of a web application as a collection of loose, > independent and atomic services that can be requested individually to > form a coherent whole (even if those services are tightly related). > Having each individual function broken out in its own class jives with > that perception a little better. Web application has URLs after all. In Struts each action is usually associated with its own action mapping, so with one mapping it is easier to control browser history list. > Lastly, I don't like the idea that I can't really guarantee what is > going to be executed. What I mean is that if I have a mapping that uses > a particular regular Action, I know for sure precisely what is going to > be executed if that URL is requested. With a DispathAction though, I > have no such guarantee because it's based on a parameter that could be > fudged. Leaves a little more room for hackery IMO. The method that is called from browser will be executed, what to think about? Parameter can be fudged, but so can URL with action mapping. Same difference. Every method simply has to verify that it can be called in current app state, that is all. If you don't like to stick method name in browser, use lookup map. > I don't mean to try and convince anyone by the way... I already know I'm > in the minority :) I *am* trying to convince you ;-) Hmm, I know that *I* am in minority, what a coincidence :) > Maybe it doesn't feel right because using a dispatch action is effectively > using an action as a controller, instead of using the controller as a > controller? That's the main reason I don't like them, and _never_ use them. The rules are there to break them ;-) Consider that Action + ActionForm define one logical entity: a page. No, not even a page, a resource. Recall how it is done in ASP.NET: markup + backing class. So, Action + ActionForm is a backing class, having lifecycle, input events and one or more views. This is even better than ASP.NET, action-style and page-style working together. Fixing cancel thing by fixing DispatchAction is the best of both worlds, word. :) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
