I'm using Struts 1.0, and have a process with a set of related event handlers which I have grouped into a single XXXXDispatchAction class. Each event has a set of assertions (some similar, some different) which must pass before any (even form validation) processing occurs.
I have basically broken down the assertions into 3 categories: 1. Assertions that are common to all events. 2. Assertions that are common to a set of related events. 3. Assertions that are specific to an event. Assertions that fall under the first category can be checked at processPreprocess() level or using some Filter and circumvents any processing if it fails. Assertions that fall under the last two categories cannot be handled before anything else related to the event gets processed. That is, assertions that fall under category 2 would usually be handled by some SuperAction template method, but the ActionForm is processed before the SuperAction gets processed. And assertions that fall under category 3 could be handled at the XXXXAction level, but is post ActionForm processing as well. I guess, one way to handle this using standard Struts components, would be to use Action chaining. Certain Action classes could act as wrappers around an assertion or a group of assertions. The action mapping would not define a form and would merely forward to the target handler or another assertion upon successful processing. If the assertion failed, then it would forward to the appropriate location. I can see where this could potentially create quite a complex action mapping definition in the struts-config file for a set of related events. For example, creating a user account where assertions 1 and 2 must pass before processing the request. <action path="/user/account/create/assertion1" type="com.company.web.assertion.SomeAssertion" scope="request" input="/WEB-INF/user/account/create.jsp"> <forward name="success" path="/do/user/account/create/assertion2"/> <forward name="failure" path="/WEB-INF/user/account/error.jsp"/> </action> <action path="/user/account/create/assertion2" type="com.company.web.assertion.AnotherAssertion" scope="request" input="/WEB-INF/user/account/create.jsp"> <forward name="success" path="/do/user/account/create"/> <forward name="failure" path="/WEB-INF/user/account/error.jsp"/> </action> <action path="/user/account/create" type="com.company.web.action.user.account.UserAccountController" name="userAccountForm" scope="request" validate="true" input="/WEB-INF/user/account/create.jsp" parameter="create"> <forward name="success" path="/WEB-INF/user/account/detail.jsp"/> <forward name="failure" path="/WEB-INF/user/account/error.jsp"/> </action> A potential problem here is the /do/user/account/create action could be invoked directly, circumventing the assertions. Is it too convoluted to think that it might be nice to have something like the following: <action path="/user/account/create" type="com.company.web.action.user.account.UserAccountController" name="userAccountForm" scope="request" validate="true" input="/WEB-INF/user/account/create.jsp" parameter="create"> <assertion type="com.company.web.assertion.SomeAssertion" path="/WEB-INF/user/account/error.jsp"/> <assertion type="com.company.web.assertion.AnotherAssertion" path="/WEB-INF/user/account/error.jsp"/> <forward name="success" path="/WEB-INF/user/account/detail.jsp"/> <forward name="failure" path="/WEB-INF/user/account/error.jsp"/> </action> In this configuration, the assertions would be processed in order they appear in the action element, and iff they all pass, then other processing would proceed. The path attribute in each assertion element defines the url to forward/redirect to if the assertion fails. The assertion checks would either come after processing the mapping in ActionServlet for Struts 1.0.x or after role checking in the RequestProcessor in Struts 1.1x, in either case, directly before processing the form. I have been looking at the LivingLogic's Workflow Extension which contains an authentication mechanism, but it doesn't appear to offer the forwarding granularity that I need and I'm forced to extend their Action class. My ultimate goal here is to have reusable assertions, be able to declaratively define them and their order, and to isolate business processing from assertions. Is there a more elegant solution for this? robert -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
