If I use multiple mappings, then I end up having something like this (only the input tag for validator is included): For Updates: <action path="/FooActionUpdate" type="com.myco.editors.FooAction" name="FooForm" scope="request" input=".editor.fooUpdate" parameter="dispatchAction"> <forward name="edit" path=".editor.fooUpdate"/> <forward name="top" path=".editor. fooTop"/> </action> For Creates: <action path="/FooActionCreate" type="com.myco.editors.FooAction" name="FooForm" scope="request" input=".editor.fooCreate" parameter="dispatchAction"> <forward name="edit" path=".editor. fooCreate"/> <forward name="top" path=".editor. fooTop"/> </action> For Selection: <action path="/FooActionTop" type="com.myco.editors.FooAction" name="FooForm" scope="request" input=".editor.fooTop" parameter="dispatchAction"> <forward name="top" path=".editor. fooTop"/> </action> For Non-Editting: <action path="/FooActionNoEdit" type="com.myco.editors.FooAction" name="FooForm" scope="request" parameter="dispatchAction"> <forward name="view" path=".editor. fooView"/> <forward name="confirmDelete" path=".editor. fooConfirm"/> <forward name="top" path=".editor. fooTop"/> </action> The only thing that differs between the mapping definitions is the path and the forwards that are available to the definition. Having the repetitive definition blocks just doesn't seem right. If I (or another developer) go in to make any changes to the mapping, then I have three or more sets of mapping to analyze and possibly change. That just seems messy and prone to error.
Nick -----Original Message----- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 18, 2003 11:00 PM To: Struts Users Mailing List Subject: Re: Validator with LookupDispatchAction and Tiles ----- Original Message ----- From: "Brandon Goodin" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, June 18, 2003 9:33 PM Subject: RE: Validator with LookupDispatchAction and Tiles > IMO. Consolidating Actions and avoiding mulitple action mappings is cleaner > and easier to identify functionality. Inevitably you have to come back to > the app to make updates. When you do come back it's a whole lot easier to > indentify an action according to it's operative functionality. The added > advantage of LookupDispatchAction is also the i18n button naming, easier > management of mulitple buttons in the same form and the translation of > button names to appropriate method names. Agree with you. I am a little bit suspicious if someone still *complains* too many action mappings after being consolidated by the dispatch action for some reasons. Jing > > Brandon Goodin > > -----Original Message----- > From: Jing Zhou [mailto:[EMAIL PROTECTED] > Sent: Wednesday, June 18, 2003 8:09 PM > To: Struts Users Mailing List > Subject: Re: Validator with LookupDispatchAction and Tiles > > > > ----- Original Message ----- > From: "Dee" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, June 18, 2003 7:58 PM > Subject: Validator with LookupDispatchAction and Tiles > > > > Hi, > > > > > > > > My teammate and I have looked through the message archives (and > > different web sites) and not been able to find a thread/site that > > discusses how to handle this situation. > > > > > > > > We are developing a web-app with multiple editors, each of which has a > > Selection page where the user decides to Create, Read, Update, or View > > the object supported by that editor. Each Action Class handles the CRUD > > functions for one object type and sub-classes LookupDispatchAction. We > > are constructing the pages using the Tiles framework. > > > > > > > > Now the fun part: We are implementing Validator. The client-side > > validation (javascript) works fine, but we have an issue with the > > server-side validation. When the validation fails, we should return to > > the page that had the error. I.E. When the user is creating and has a > > server-side validation error, we need to return to the create page, > > which is a tiles definition.similarly with the Update function, we need > > to return to the update tiles definition. > > > > > > > > The input tag in the action-mapping seems to be the answer, but it would > > require multiple action mappings to have an input tag for each of the > > tiles-mappings that used validator. > > > > > > > > My question: Is the input tag and multiple-action mappings the right > > way to accomplish our goals? The use of multiple action-mappings seems > > messy; is there a better way? > > Could you elaborate why you think the use of multiple > action mappings seems messy? > I am asking the question from a research point of view. > > Jing > > > > > > > > > Thanks for any advice or thoughts. > > > > Nick > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]