There are some recent attempts to address the problem. I include the message below. It might be helpful.
Jing Netspread Carrier http://www.netspread.com -----Original Message----- From: Jing Zhou [mailto:[EMAIL PROTECTED] Sent: Thursday, June 19, 2003 12:52 PM To: Struts Users Mailing List Subject: Re: Validator with LookupDispatchAction and Tiles I can see your problems now. It seems to me that the dispatch action can *consolidate* different CRUD operations into one action mapping, but it fails to *consolidate* the corresponding input attribute for each of the CRUD operations. I just get an idea to *fix* the problem so that you have one action mapping: <action path="/FooCRUDOperation" type="com.myco.editors.FooAction" name="FooForm" scope="request" input="/FooCRUDInput.do" parameter="dispatchAction"> <forward name="edit" path=".editor.foo.Update"/> <forward name="edit" path=".editor.fooCreate"/> <forward name="view" path=".editor.fooView"/> <forward name="top" path=".editor.fooTop"/> </action> In the action class for the path /FooCRUDInput.do, you forward according to the parameter "dispathchAction". Another way I did is in the hyper action wizards in Carrier. The CRUD operations and the phased validation model are naturally integrated. It will help people to prototype their projects quickly. Jing ----- Original Message ----- From: "Nick" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Thursday, June 19, 2003 3:45 AM Subject: RE: Validator with LookupDispatchAction and Tiles > 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: "Larry Zappeterrini" <[EMAIL PROTECTED]> To: "'Struts Users Mailing List'" <[EMAIL PROTECTED]> Sent: Monday, June 23, 2003 10:17 AM Subject: RE: DispatchAction and input > You have to define separate action mappings for each forward in order for > the validation to behave properly. Each mapping needs its own input forward > to use Struts' validation framework. > > This seems to be a recurring problem that new users attempting to utilize > DispatchAction with validation meet up with. The architecture of > DispatchAction would quite naturally lead a developer to put several > forwards into one mapping if they are related in some fashion, using the > DispatchAction to facilitate the command design pattern. It works very well > until validation of user input is necessary. Since validation relies on the > input attribute of the mapping, and a mapping can only have one input, every > forward in that mapping will display the same view defined by that input if > a validation error occurs. I don't believe that the original intentions > behind using DispatchAction accounted for this usage and the problems that > it introduces. But since this seems to be a common problem (just search the > archives), maybe there should be an attempt to address it. > > Larry > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
