Team, After successfully testing the new org.apache.struts.dispatcher package (by retrofitting a current application of mine), it is in great shape for anyone else to try. Here are some highlights:
1) New ExecuteDispatcher command for ComposableRequestProcessor that delegates to a Dispatcher instance and processes the return value. 2) Choice to assign a default Dispatcher (via chain config property) for any mapping that does not use the new @dispatcher config attribute. 3) New Dispatcher interface that forms a hierarchy of dispatching strategies. 4) New MethodResolver interface that defines the know-how of selecting the correct Method handle and building its arguments. If a developer were to use the servlet subpackage, these method signatures are supported out of the box: * [void|String|ActionForward] execute() * [void|String|ActionForward] execute(ActionContext) * [void|String|ActionForward] execute(ServletActionContext) * [void|String|ActionForward] execute(ActionMapping, ActionForm, HttpServletRequest, HttpServletResponse) Writing your own MethodResolver will allow different return types and method signatures. I bet some clever Ajax developer could take advantage of this kind of support. Anyway, based on an eye-ball guestimate, I think about 30% of my Struts code has now shrunk due to cleaner method signatures and corresponding javadoc method comments. That was one of my big goals: conciseness. PS: Is this architecture useful for Struts 2? Paul --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org For additional commands, e-mail: dev-h...@struts.apache.org
