struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jing Zhou" <j...@netspread.com>
Subject Re: Validator with LookupDispatchAction and Tiles
Date Thu, 19 Jun 2003 17:52:25 GMT
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" <nmohler@adelphia.net>
To: "'Struts Users Mailing List'" <struts-user@jakarta.apache.org>
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: Jing Zhou [mailto:jing@netspread.com] 
> 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" <mail@phase.ws>
> To: "Struts Users Mailing List" <struts-user@jakarta.apache.org>
> 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:jing@netspread.com]
> > Sent: Wednesday, June 18, 2003 8:09 PM
> > To: Struts Users Mailing List
> > Subject: Re: Validator with LookupDispatchAction and Tiles
> >
> >
> >
> > ----- Original Message -----
> > From: "Dee" <nmohler@adelphia.net>
> > To: <struts-user@jakarta.apache.org>
> > 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: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: struts-user-help@jakarta.apache.org
> >
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org


Mime
View raw message