Re: Validation of errors and re-population of request
> If you find an error during the validate() and fordward to the action, the > validate() method will be called again before the execution of the > perform(), because the action will try to validate the form is receiving, > and you'll be in a loop. > I 'm experiencing that problem. > I appreciate if you could help me. > > > Re: Validation of errors and re-population of request > > * From: Bill Clinton > * Subject: Re: Validation of errors and re-population of request > * Date: Fri, 03 Aug 2001 21:37:20 -0700 > > Tim, > I'm not sure this will work for you, but if it does, it may be the > easiest solution. I am assuming that you have a "failure" forward in > the Delete action that sends the user back to the list page. Instead of > mapping this forward to the list page, map it to the list action. That > way, the action errors (or non-struts error message) that you save in > the request object will still be there, and it will pick up the vector > in the list action before it dispatches to the list page. > > Bill > > Tim Trentham wrote: > > > I'm wondering if there is a "best practice" or standard Struts way of > > handling repopulation of request attributes needed for a page after an > > error. > > > > For instance, I have a list of contacts with a checkbox next to each > one. > > The list is generated by the logic:iterate and multibox tags using a > vector > > that is placed in the request by the action that forwards to the page > that > > displays the list. The user can select contacts from the list and delete > > them. > > > > If the user clicks the delete button and there are no users checked, my > > validate method throws them back to the page telling them that they need > to > > pick something. Of course, the vector is no longer in the request for > > display, so you see the error message, but no users. > > > > I did find a two things in past posts, but nothing really promising... > > > > 1) > > repopulation occurs in the reset method > > > <http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05423.html> > > > > but this means that you are re-populating the request with the dropdown > list > > even if there aren't any errors, which seems like a waste of resources. > > also, you still have to populate the first time from somewhere else as > the > > forms reset() method isn't called until after the first time the page is > > displayed. > > > > 2) > > repopulation occurs in validate method > > > <http://www.mail-archive.com/struts-user@jakarta.apache.org/msg11305.html> > > > > this is what i'm looking at doing, but once again, i have to do it in > two > > places: the original action that generates the list in the jsp page and > then > > in the validate method of the form if there is an error. > > > > I also have the additional problem of keeping track of which vector to > > re-generate. I display the contacts in blocks of 25, so if you are on > the > > second block of 25 and you click delete with no contacts checked, I need > to > > know that I need to re-generate the second block and not the first. > > > > I'm wondering if others have come up with a good way of handling this > before > > I go off and reinvent the wheel. > > > > Thanks. > > > > Tim > > > > > > Tim Trentham > > Platform Development > > @hand Corporation > > [EMAIL PROTECTED] > > > > > > Oscar Guindzberg > EDS - Interbanking > Arias 1851 > Capital Federal (1429) > > * 4704-3527 > * [EMAIL PROTECTED] > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: Validation of errors and re-population of request
Tim, I'm not sure this will work for you, but if it does, it may be the easiest solution. I am assuming that you have a "failure" forward in the Delete action that sends the user back to the list page. Instead of mapping this forward to the list page, map it to the list action. That way, the action errors (or non-struts error message) that you save in the request object will still be there, and it will pick up the vector in the list action before it dispatches to the list page. Bill Tim Trentham wrote: > I'm wondering if there is a "best practice" or standard Struts way of > handling repopulation of request attributes needed for a page after an > error. > > For instance, I have a list of contacts with a checkbox next to each one. > The list is generated by the logic:iterate and multibox tags using a vector > that is placed in the request by the action that forwards to the page that > displays the list. The user can select contacts from the list and delete > them. > > If the user clicks the delete button and there are no users checked, my > validate method throws them back to the page telling them that they need to > pick something. Of course, the vector is no longer in the request for > display, so you see the error message, but no users. > > I did find a two things in past posts, but nothing really promising... > > 1) > repopulation occurs in the reset method > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05423.html > > but this means that you are re-populating the request with the dropdown list > even if there aren't any errors, which seems like a waste of resources. > also, you still have to populate the first time from somewhere else as the > forms reset() method isn't called until after the first time the page is > displayed. > > 2) > repopulation occurs in validate method > http://www.mail-archive.com/struts-user@jakarta.apache.org/msg11305.html > > this is what i'm looking at doing, but once again, i have to do it in two > places: the original action that generates the list in the jsp page and then > in the validate method of the form if there is an error. > > I also have the additional problem of keeping track of which vector to > re-generate. I display the contacts in blocks of 25, so if you are on the > second block of 25 and you click delete with no contacts checked, I need to > know that I need to re-generate the second block and not the first. > > I'm wondering if others have come up with a good way of handling this before > I go off and reinvent the wheel. > > Thanks. > > Tim > > > Tim Trentham > Platform Development > @hand Corporation > [EMAIL PROTECTED]
Validation of errors and re-population of request
I'm wondering if there is a "best practice" or standard Struts way of handling repopulation of request attributes needed for a page after an error. For instance, I have a list of contacts with a checkbox next to each one. The list is generated by the logic:iterate and multibox tags using a vector that is placed in the request by the action that forwards to the page that displays the list. The user can select contacts from the list and delete them. If the user clicks the delete button and there are no users checked, my validate method throws them back to the page telling them that they need to pick something. Of course, the vector is no longer in the request for display, so you see the error message, but no users. I did find a two things in past posts, but nothing really promising... 1) repopulation occurs in the reset method http://www.mail-archive.com/struts-user@jakarta.apache.org/msg05423.html but this means that you are re-populating the request with the dropdown list even if there aren't any errors, which seems like a waste of resources. also, you still have to populate the first time from somewhere else as the forms reset() method isn't called until after the first time the page is displayed. 2) repopulation occurs in validate method http://www.mail-archive.com/struts-user@jakarta.apache.org/msg11305.html this is what i'm looking at doing, but once again, i have to do it in two places: the original action that generates the list in the jsp page and then in the validate method of the form if there is an error. I also have the additional problem of keeping track of which vector to re-generate. I display the contacts in blocks of 25, so if you are on the second block of 25 and you click delete with no contacts checked, I need to know that I need to re-generate the second block and not the first. I'm wondering if others have come up with a good way of handling this before I go off and reinvent the wheel. Thanks. Tim Tim Trentham Platform Development @hand Corporation [EMAIL PROTECTED]
