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 Sat, 21 Jun 2003 01:06:52 GMT
Sandeep,

I'm not sure I understand why you think we're overriding default
behaviors.  We generally allow the Struts, Tiles, & Validator frameworks
to do their thing without modification.

Currently, we only have one modification to Struts' general behaviors.
That modification is in the Struts Action servlet to load some objects
into the application context.

We're considering the modification to the way that Validator is invoked
because of the way that we currently have our forwards mapped...a
forward for Item Selection, Create, Read, Update, and Delete
(confirmation).  The input tag requires a single "came from" reference
that will be used if the validations fail.  Unless we split into
multiple action mapping definitions, the input tag really hurts us.

Jing's idea seems like an idea that will work and be fairly simple to
implement, but I am always open to suggestions :-)

Nick

-----Original Message-----
From: Sandeep Takhar [mailto:sandeep_takhar@yahoo.com] 
Sent: Friday, June 20, 2003 1:35 PM
To: Struts Users Mailing List
Subject: RE: Validator with LookupDispatchAction and Tiles

You seem to be overriding default behaviour alot in
your framework.  I am not suggesting that this never
occurs since it will certainly occur at some points,
but will this way not make a lot of changes?

sandeep
--- Nick <nmohler@adelphia.net> wrote:
> 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
> 


__________________________________
Do you Yahoo!?
SBC Yahoo! DSL - Now only $29.95 per month!
http://sbc.yahoo.com

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