Niall's response has softened my position on the built-in action dispatching. In my own projects, I went ahead and created a common BaseAction which all my other actions extend from. The BaseAction uses EventDispatcherAction with a pre-written execute method for the dispatching; subclasses just override execute() if they don't want it or provide a different dispatcher in the constructor.
Because it was so easy to write, I am +0 with Michael's idea. It's a good idea, but because it's so easy to implement, I don't know if it belongs in the Action. I just don't know (honestly). It's a very good idea but we have to corporately decide if we want that bolted into the framework. Paul Michael Jouravlev <[EMAIL PROTECTED]> wrote: On 6/28/06, Niall Pemberton wrote: > I haven't read Michaels latest write up, so I don't know if its > substantially different, but last time I looked the only reason for > integrating the "dispatch" style into Action was (IMO) to encourage > its use. > If thats still true then my opinion is unchanged: > > http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 * Having dispatch stuff in Action will encourage using this pattern, I have no doubt about that. * Events/hadnlers definition becomes first-class element of action mapping. * Events/hadnlers can be defined in a clean well-documented fashion. * And after all, It does not hurt anywone. Really. :-) http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > Personally I'm against this because IMO it just adds > confusion/complexity to the Action class that is unnecessary > for users who don't want to use the "dispatch" style. Those who do not want to use it will just skip a chapter in the manual. Nothing else will affect them. The only visible part is event/handler mapping and they won't see it if they do not use it. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > I also think that the > current provision for "dispatch" flavours isn't a real barrier for > people to adopt the style that you're promoting here. I think if this approach were more official people would be more inclined to use it. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > Simply making the code changes you suggest will not shift > people's mindset - you would need to document the choices > available. I will do my best to document it, that's for sure. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > documentation is more important than merging the dispatch > logic into the Action class and if Action and DispatchAction > flavours were better documented you could achieve the same > without changing the code at all. The code in action would be cleaner, the event mapping would be clean and visible. http://marc.theaimsgroup.com/?l=struts-user&m=114716977729347&w=2 > I don't use any of the DispatchAction/ActionDispatcher flavours > and am happy with "simple" Actions. Then you won't even notice the change. Really, it does not affect you or anyone else who does not use this style. I am preparing an updated documentation on actions in Wiki. It already saw like 40 updates and will see even more :) I want to build the solid base about how common use cases are handled. I will do my best not to promote one style over the other. > I also think that the concrete Action class tied to the servlet API is > legacy Then why do you care about me enhancing it?! ;-) > and that if you want to inovate then the effort is better spent > focusing on the support for CoR/CoC in Struts 1.3 and the Command > interface (Commons Chain 1.1 even has a DispatchCommand :-) I use Action as request endpoint. I don't need a lot of features from it. I doubt that I will be using commands anytime soon instead of actions. If I wanted to use them as interceptors, I will always be able to terminate the chain with Action (tenses?) Command is only better because it does not throw HTTP stuff right in one's face. Is it really better? Maybe just for testing. From webapp point of view, Command is as bad as Action. Meaning that HttpServlet has doGet() and doPost() and therefore forces people to think what kind of request they are processing and what method is better to use. Action's only execute() method blurries vision, makes everything a web service so to speak. Many do not think on what kind of request they are actually processing and in what other interactions this Action or a business/UI object represented by this action participates. After all, until developers move on to GWT or move back to Swing, they will continue developing against 1995 protocol. It is important to consider features, quirks and requirements of this protocol despite popular opinion that protocol-agnostic application is better thing. > http://jakarta.apache.org/commons/chain/changes-report.html > http://jakarta.apache.org/commons/chain/apidocs/index.html > > The great benefit of Chain means that having an alternative set of > "request processing" steps becomes much easier and you could develop > something more elegant to support your event style which would > probably mean that the user doesn't need to use either the > DispatchAction or ActionDispatcher at all. Um, I have to think on this paragraph, I have not got it yet, but maybe I will get it later, after my head stop aching and I reread it couple more times :) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------- Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2ยข/min or less.
