struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Nick" <nmoh...@adelphia.net>
Subject RE: Validator with LookupDispatchAction and Tiles
Date Thu, 19 Jun 2003 21:54:42 GMT
Jing,

I like your idea.  We are going to try a slightly modified version (we
have "framework" issues that aren't ironed out) that will take advantage
of your idea and keep us from having new problems.

We'll have a primary mapping, where we do the initial processing for a
given user action.  There will be a second mapping that will handle
Validation failures.  The second will use the same action class as the
first, but it won't invoke validator.

In the form, we'll override validate().  When the form fails the
validation, we'll modify the "dispatchAction" and put it back into the
request, making it "addFailedValidation" or "editFailedValidation".  The
ActionErrors will be returned as they normally would be.

The input tag would point to the second mapping, whereby the current
"dispatchAction" value will put us into the method to handle the
failure.  The method will take care of putting elements that are needed
to build the page (not in the form) into the request context.  Those
elements will be reference items (for pick lists, etc.) that we don't
carry in the form.  In the future, we'll probably put those elements
into the Application Context, but not today :-)  The method will then
find the appropriate forward to go back to the tiles definition that the
generated the validation failure.

In theory, this sounds reasonable...it might even work...any thoughts?

Thanks for the suggestion!
Nick

-----Original Message-----
From: Jing Zhou [mailto:jing@netspread.com] 
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" <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


---------------------------------------------------------------------
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