Re: best practice to avoid chaining actions
Very interesting thread, Thanks a lot Nico. Hi, There was a long discussion about action chainning some time ago. http://marc.theaimsgroup.com/?l=struts-user&m=104427309720653&w=2 And as summarized in the above discussion, I think if you are using 2 actions to complete 1 logical function, then it is bad design.And that is what I think the approach suggested by you looks like. To answer you specific question,like already suggested, I will put the validation logic in the form bean(SO that same validation can be used in some other action if it is using same form ) and then put the validation call in the action(Something like form.validate) and forward to error if the validation fails. And if validation succeeds, go ahead with normal data processing(which is data retrieval in this case.) HTH. regards, Shirish -Original Message- From: Krishnakumar N [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 10:56 AM To: Struts Users Mailing List Subject: RE: best practice to avoid chaining actions > -Original Message- > From: Nicolas De Loof [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2003 2:58 PM > To: Struts Users Mailing List > Subject: Re: best practice to avoid chaining actions > > > > > > Hello, > > > > If action chaining is a design error, then the struts-example that > > comes with struts distributions has a design error, saveSubscription > > forwards to editRegistration.do! > > > > Anyway, what I do is keep validation off action classes, by moving > > them off to action forms using validator and/or overridden > validate() > > methods. (Business logic validations that need access to > the data model must > > be in the model ofcourse, and not in action classes.) > > You're right, my description was a little short about this : > > In Action1, we use business model validation methods to > validate some form datas : to know if user is allowed to use > some datas he entered for the business process he want's to begin. > If the logic itself is in the model and action1 only makes the call to validate the user's inputs, I would guess it is ok to put it in the same action that fetches and populates data for page2. > > > > > Cheers, > > Krishna > > > > > - > 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]
RE: best practice to avoid chaining actions
Hi, There was a long discussion about action chainning some time ago. http://marc.theaimsgroup.com/?l=struts-user&m=104427309720653&w=2 And as summarized in the above discussion, I think if you are using 2 actions to complete 1 logical function, then it is bad design.And that is what I think the approach suggested by you looks like. To answer you specific question,like already suggested, I will put the validation logic in the form bean(SO that same validation can be used in some other action if it is using same form ) and then put the validation call in the action(Something like form.validate) and forward to error if the validation fails. And if validation succeeds, go ahead with normal data processing(which is data retrieval in this case.) HTH. regards, Shirish -Original Message- From: Krishnakumar N [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 10:56 AM To: Struts Users Mailing List Subject: RE: best practice to avoid chaining actions > -Original Message- > From: Nicolas De Loof [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2003 2:58 PM > To: Struts Users Mailing List > Subject: Re: best practice to avoid chaining actions > > > > > > Hello, > > > > If action chaining is a design error, then the struts-example that > > comes with struts distributions has a design error, saveSubscription > > forwards to editRegistration.do! > > > > Anyway, what I do is keep validation off action classes, by moving > > them off to action forms using validator and/or overridden > validate() > > methods. (Business logic validations that need access to > the data model must > > be in the model ofcourse, and not in action classes.) > > You're right, my description was a little short about this : > > In Action1, we use business model validation methods to > validate some form datas : to know if user is allowed to use > some datas he entered for the business process he want's to begin. > If the logic itself is in the model and action1 only makes the call to validate the user's inputs, I would guess it is ok to put it in the same action that fetches and populates data for page2. > > > > > Cheers, > > Krishna > > > > > - > 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]
RE: best practice to avoid chaining actions
> -Original Message- > From: Nicolas De Loof [mailto:[EMAIL PROTECTED] > Sent: Friday, November 21, 2003 2:58 PM > To: Struts Users Mailing List > Subject: Re: best practice to avoid chaining actions > > > > > > Hello, > > > > If action chaining is a design error, then the struts-example that > > comes with struts distributions has a design error, saveSubscription > > forwards to editRegistration.do! > > > > Anyway, what I do is keep validation off action classes, by moving > > them off to action forms using validator and/or overridden > validate() > > methods. (Business logic validations that need access to > the data model must > > be in the model ofcourse, and not in action classes.) > > You're right, my description was a little short about this : > > In Action1, we use business model validation methods to > validate some form datas : to know if user is allowed to use > some datas he entered for the business process he want's to begin. > If the logic itself is in the model and action1 only makes the call to validate the user's inputs, I would guess it is ok to put it in the same action that fetches and populates data for page2. > > > > > Cheers, > > Krishna > > > > > - > 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]
Re: best practice to avoid chaining actions
> Hello, > > If action chaining is a design error, then the struts-example that > comes with struts distributions has a design error, saveSubscription > forwards to editRegistration.do! > > Anyway, what I do is keep validation off action classes, by moving > them off to action forms using validator and/or overridden validate() > methods. (Business logic validations that need access to the data model must > be in the model ofcourse, and not in action classes.) You're right, my description was a little short about this : In Action1, we use business model validation methods to validate some form datas : to know if user is allowed to use some datas he entered for the business process he want's to begin. > > Cheers, > Krishna > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: best practice to avoid chaining actions
Hello, If action chaining is a design error, then the struts-example that comes with struts distributions has a design error, saveSubscription forwards to editRegistration.do! Anyway, what I do is keep validation off action classes, by moving them off to action forms using validator and/or overridden validate() methods. (Business logic validations that need access to the data model must be in the model ofcourse, and not in action classes.) Cheers, Krishna -Original Message- From: Nicolas De Loof [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2003 2:05 PM To: Struts Users Mailing List Subject: best practice to avoid chaining actions Hi all, I've read on this list that chaining actions is considered as a design error. On the project I'm working on, some developers need to make some business validation on a form before going to the next page. This validation occurs in an Action class, let's say Action1. >From business validation point of view, Action1 return "success" or "error". Next page needs some pre-computing to select JSP and display, because of some list of values that are time and user-dependant. >From next-page precomputing point of view, forward can be "simple-select" or "multi-select" What is the best way : - Action1 validates, Action2 computes datas before page2 display, and we need to chain Action1 and Action2. - Action1 both validates ans computes datas for page2. It doesn't seems to be good as this mix to roles in Action1 and we cannot display page2 without validating. Is they're a "good way" to do this without some workflow extension ? Thanks for any help or suggestion. - 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]
best practice to avoid chaining actions
Hi all, I've read on this list that chaining actions is considered as a design error. On the project I'm working on, some developers need to make some business validation on a form before going to the next page. This validation occurs in an Action class, let's say Action1. >From business validation point of view, Action1 return "success" or "error". Next page needs some pre-computing to select JSP and display, because of some list of values that are time and user-dependant. >From next-page precomputing point of view, forward can be "simple-select" or >"multi-select" What is the best way : - Action1 validates, Action2 computes datas before page2 display, and we need to chain Action1 and Action2. - Action1 both validates ans computes datas for page2. It doesn't seems to be good as this mix to roles in Action1 and we cannot display page2 without validating. Is they're a "good way" to do this without some workflow extension ? Thanks for any help or suggestion. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
