> Though, I suppose, if someone really, really doesn't want to forward > control, > another approach would be to use a "ViewAction" as a base class, and > then > call a render method at the end of perform. > > public ActionForward render( > ActionMapping mapping, ActionForm form, > HttpServletRequest request, HttpServletResponse response) > throws IOException, ServletException; > > If the rendering process needed to be tweaked, then the subclasses would > all inherit the changes on the next compile. > > If you had more than one rendering technique, there could be more than > one base class in the hierarchy, and if the interfaces were compatible, > you could just change which one it extends. > > If the base class extended org.apache.struts.actions.DispatchAction, > then you could also call the render method directly, and forego the > subclass. > > This eliminates another pass through the forward guantlet, and the > ActionForm and ActionMapping would be unchanged. > > If "render" were used an adapter, the rendering logic could be put > into another class, that render would call in the same way > other Actions call business logic, so that the whole thing is > not hopelessly bound to Struts. > > An embarrassment of riches, this framework ;-) > I want to stop myself, but can't resist now. This is exactly the design we talked about: with only one difefrence: that should reside one layer up, in the controler. It feds both the servlet dispatcher techniques and the other possibilities. You could use even pluggable adapters atc. etc. Now, I'll really stop on this. Promise.
incze -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
