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]
