Hai, thanks for your response. 1. The login example was just that, an example. My problem extends beyond the simple example.
2. DispatchAction is used to solve the spagetti type logic exemplified by your example below. 3. This does not solve my problem of needing to apply certain constraints to certain events handled by a single DispatchAction. robert > -----Original Message----- > From: Hoang, Hai [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 23, 2002 10:07 AM > To: 'Struts Users Mailing List' > Subject: RE: Design Advice: Using DispatchAction > > > You don't need to use the DispatchAction for this. Call the isLoggedIn > method whenever you need it. And make sure to have the > actionName property > on your form. > > > > if (!isLoggedIn(request)) > { > return new ActionForward(Constants.GLOBAL_FORWARD_LOGON, true); > } > > > ApplicationForm applicationForm = (ApplicationForm) form; > String action = applicationForm.getActionName(); > if (action.equals(userContainer.getMessage(Constants.BUTTON_CANCEL))) > { > doAdd(mapping, applicationForm, request, response, userContainer); > } > else if (action.equals(userContainer.getMessage(Constants.BUTTON_ADD))) > { > doAdd(mapping, applicationForm, request, response, userContainer); > } > else if (action.equals(userContainer.getMessage(Constants.BUTTON_SAVE))) > { > doSave(mapping, applicationForm, request, response, userContainer); > } > else if (action.equals(userContainer.getMessage(Constants.BUTTON_EDIT)) > || > action.equals(userContainer.getMessage(Constants.BUTTON_REMOVE))) > { > doEdit(mapping, applicationForm, request, response, userContainer); > } > else if (action.equals(userContainer.getMessage(Constants.BUTTON_UPDATE))) > { > doUpdate(mapping, applicationForm, request, response, > userContainer); > } > else if (action.equals(userContainer.getMessage(Constants.BUTTON_DELETE))) > { > > doDelete(mapping, applicationForm, request, response, > userContainer); > } > return (new ActionForward(mapping.getInput())); > } > > > > -----Original Message----- > From: Robert Taylor [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, July 23, 2002 8:46 AM > To: [EMAIL PROTECTED] > Subject: Design Advice: Using DispatchAction > > I'll try to keep this as short as possible. > > Background: > I have various groupings of common events in my web app where > I would like each grouping of common events handled by a single > Action class. The DispatchAction class allows me to > do this. I want to do this because in my scenario, > the Action classes are simple proxies to my business > tier and are not reusable and I would like to keep > the number of Action classes I have to create to a minimum. > > > Problem: > The problem I am running into is that pre-processing > requirements vary within the common event groupings. For example, > let's say eventGroupA handles events 1, 2, 3, and 4. > Events 3 and 4 require that the user be logged in before > any processing occurs, but events 1 and 2 don't. > > > An idea: Assertions > What if there was a way to declaratively define an ordered > list of assertions that must be true before any processing > occurs for an action mapping. Assertions would be processed > in the order in which they appear in the action mapping > and would return an ActionForward only if it failed else it > would return null indicating that the assertion passed and > to continue processing. Any errors or messages would be > revealed to the user via ActionErrors or ActionMessages stored > in the appropriate scope. An Assertion would have access to > the action mapping so it could leverage lookups for locally > or globally defined forwards. An Assertion would implement > a Command pattern and have a single method assert() > into which the RequestProcessor would be passed the ActionForm, > ActionMapping, HttpServletRequest, and HttpServletResponse. > Basically the same arguments as Action.execute(). > > > Example struts-config with assertions: > > <assertions> > <assertion name="authenticated" > type="com.company.web.assertion.SomeAssertion"/> > <assertion name="isAdministrator" > type="com.company.web.assertion.AnotherAssertion"/> > </assertions> > > <action > path="/user/account/create" > type="com.company.web.account.UserAccountController" > name="userAccountForm" > scope="request" > validate="true" > input="/WEB-INF/user/account/create.jsp" > parameter="create"> > <assert name="authenticated"/> > <assert name="isAdministrator"/> > <forward name="success" path="/WEB-INF/user/account/detail.jsp"/> > <forward name="failure" path="/WEB-INF/user/account/error.jsp"/> > </action> > > > > Example of Assertion.assert(): > > public ActionForward assert(ActionMapping mapping, > ActionForm form, HttpServletRequest request, > HttpServletResponse response) throws Exception; > > > This solution seems to fit my needs, but I'm interested in any > feed back on > it. > Good or bad. Does it suck? Is there a better way to accomplish my > goal? Am I > way > off track? Am I close? Am I making things too complex? Is this > idea kludgy? > > > > robert > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
