Re: dificult problem, preventing population (repost)
I guess the issue is the same one you mentioned earlier which is that we have to know which action is preparing the token and which one is checking it. To do this generically means adding something to action-mapping, but since this is not an option currently then I don't think it should be since the developers of struts would have added it if this is the right spot. sandeep --- Jing Zhou [EMAIL PROTECTED] wrote: - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED]; Jing Zhou [EMAIL PROTECTED] Sent: Friday, July 18, 2003 12:37 PM Subject: Re: dificult problem, preventing population (repost) I suppose you would get the page expired if you are using noCache... So what do people do? Do they just right their own stuff. On the application that we have built over the last year - we have opened another window and with the parameters passed to the open window we have removed the menu lines. However if the user hits backspace in certain situations, this is equivalent to pressing the back button. I know the struts workflow extension proposes a solution. But what are people doing?? I guess that is the original question, but the more I think about it the more I'm curious to know what the options are. I suppose what was mentioned before about using mappings and subclassing ActionMapping may be the only way? (This is essentially what workflow does) One possible way is to add a method prepareExecute() in the action base class. After the RequestProcessor obtains the action mapping and before populates the form bean, it invokes the prepareExecute() method on the action class. If it finds anything wrong after the prepareExecute() call, it throws an exception. This way would return the logics to handle the tokens back to action developers. Is this reasonable? Any other ideas? sandeep Jing --- Jing Zhou [EMAIL PROTECTED] wrote: Hi, Sandeep, There is no clean solution to this problem, not only in Struts but also in many others ... I wish there could be a simple way to disable the Back button. But browser vendors would say once it is disabled, who is responsible to enable it. There should be some better algorithm for this problem. Jing - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED]; Jing Zhou [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 12:35 PM Subject: Re: dificult problem, preventing population (repost) Ah... I see what you mean. Yes, not thinking that clearly, but I have not done it either so that is my excuse... So I think that to make this too complicated is not good. So the original problem states that when pressing the back button that they get back to the screen. I am wondering right now that when the press the back button they should be in the submit state again and the token check should occur again? If the previous page is a submitted page, you would get Page has Expired If the previous page is retrieved by an http get method, you would do a GET again. Sometimes I wish I could pick up the phone and sort these type of things out because I'm probably missing something again. sandeep --- Jing Zhou [EMAIL PROTECTED] wrote: - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 7:49 AM Subject: Re: dificult problem, preventing population (repost) I think he meant isTokenValid(). Also the form tag will create the token and you can look at it in the source. You can check the token higher if you want (before population) by placing it in one of these methods on the requestProcessor.. My analysis shows we can't simply check the token at processPreProcess method, as an example. Because the RequestProcessor doesn't known when it should check and when it should not. It could involve more complicated logics than what we can imagine to get it done here, although it is not all impossible. If someone would like to layout a detail algorithm here, I believe some parameters in action mappings should be used. But that is easier to create *holes* than ... That's why it is a *difficult* problem :-) Jing (not sure logistically which one has the request signature more importantly which one makes sense)... This is in order: processMultipart processPath processLocale processContent processNoCache
Re: dificult problem, preventing population (repost)
I suppose you would get the page expired if you are using noCache... So what do people do? Do they just right their own stuff. On the application that we have built over the last year - we have opened another window and with the parameters passed to the open window we have removed the menu lines. However if the user hits backspace in certain situations, this is equivalent to pressing the back button. I know the struts workflow extension proposes a solution. But what are people doing?? I guess that is the original question, but the more I think about it the more I'm curious to know what the options are. I suppose what was mentioned before about using mappings and subclassing ActionMapping may be the only way? (This is essentially what workflow does) sandeep --- Jing Zhou [EMAIL PROTECTED] wrote: Hi, Sandeep, There is no clean solution to this problem, not only in Struts but also in many others ... I wish there could be a simple way to disable the Back button. But browser vendors would say once it is disabled, who is responsible to enable it. There should be some better algorithm for this problem. Jing - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED]; Jing Zhou [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 12:35 PM Subject: Re: dificult problem, preventing population (repost) Ah... I see what you mean. Yes, not thinking that clearly, but I have not done it either so that is my excuse... So I think that to make this too complicated is not good. So the original problem states that when pressing the back button that they get back to the screen. I am wondering right now that when the press the back button they should be in the submit state again and the token check should occur again? If the previous page is a submitted page, you would get Page has Expired If the previous page is retrieved by an http get method, you would do a GET again. Sometimes I wish I could pick up the phone and sort these type of things out because I'm probably missing something again. sandeep --- Jing Zhou [EMAIL PROTECTED] wrote: - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 7:49 AM Subject: Re: dificult problem, preventing population (repost) I think he meant isTokenValid(). Also the form tag will create the token and you can look at it in the source. You can check the token higher if you want (before population) by placing it in one of these methods on the requestProcessor.. My analysis shows we can't simply check the token at processPreProcess method, as an example. Because the RequestProcessor doesn't known when it should check and when it should not. It could involve more complicated logics than what we can imagine to get it done here, although it is not all impossible. If someone would like to layout a detail algorithm here, I believe some parameters in action mappings should be used. But that is easier to create *holes* than ... That's why it is a *difficult* problem :-) Jing (not sure logistically which one has the request signature more importantly which one makes sense)... This is in order: processMultipart processPath processLocale processContent processNoCache processPreProcess * looks promising processMapping processRoles processActionForm processPopulate 1st and 3rd are normally done in the action class. One that handles the display and the one that you are submitting to. sandeep --- Adam Hardy [EMAIL PROTECTED] wrote: I'm sure a quick look in the source code would give you what you want - try looking at isTokenValue() in Action.java Jing Zhou wrote: - Original Message - From: Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 6:57 PM Subject: dificult problem, preventing population (repost) I have the following scenario occuring. I have a form with several fields on it (the fields are sourced to a collection in an ActionForm). I have a button that allows the removal of fields from the form (items from the collection). If a user removes a field from the form and then double submits/clicks back and reloads then an exception is thrown from BeanUtils.populate() because it attempts to take details from the (now removed field) and populate it into the object that is stored in the position it was located in the collection. Obviously since the collection is now smaller this results
Re: dificult problem, preventing population (repost)
- Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED]; Jing Zhou [EMAIL PROTECTED] Sent: Friday, July 18, 2003 12:37 PM Subject: Re: dificult problem, preventing population (repost) I suppose you would get the page expired if you are using noCache... So what do people do? Do they just right their own stuff. On the application that we have built over the last year - we have opened another window and with the parameters passed to the open window we have removed the menu lines. However if the user hits backspace in certain situations, this is equivalent to pressing the back button. I know the struts workflow extension proposes a solution. But what are people doing?? I guess that is the original question, but the more I think about it the more I'm curious to know what the options are. I suppose what was mentioned before about using mappings and subclassing ActionMapping may be the only way? (This is essentially what workflow does) One possible way is to add a method prepareExecute() in the action base class. After the RequestProcessor obtains the action mapping and before populates the form bean, it invokes the prepareExecute() method on the action class. If it finds anything wrong after the prepareExecute() call, it throws an exception. This way would return the logics to handle the tokens back to action developers. Is this reasonable? Any other ideas? sandeep Jing --- Jing Zhou [EMAIL PROTECTED] wrote: Hi, Sandeep, There is no clean solution to this problem, not only in Struts but also in many others ... I wish there could be a simple way to disable the Back button. But browser vendors would say once it is disabled, who is responsible to enable it. There should be some better algorithm for this problem. Jing - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED]; Jing Zhou [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 12:35 PM Subject: Re: dificult problem, preventing population (repost) Ah... I see what you mean. Yes, not thinking that clearly, but I have not done it either so that is my excuse... So I think that to make this too complicated is not good. So the original problem states that when pressing the back button that they get back to the screen. I am wondering right now that when the press the back button they should be in the submit state again and the token check should occur again? If the previous page is a submitted page, you would get Page has Expired If the previous page is retrieved by an http get method, you would do a GET again. Sometimes I wish I could pick up the phone and sort these type of things out because I'm probably missing something again. sandeep --- Jing Zhou [EMAIL PROTECTED] wrote: - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 7:49 AM Subject: Re: dificult problem, preventing population (repost) I think he meant isTokenValid(). Also the form tag will create the token and you can look at it in the source. You can check the token higher if you want (before population) by placing it in one of these methods on the requestProcessor.. My analysis shows we can't simply check the token at processPreProcess method, as an example. Because the RequestProcessor doesn't known when it should check and when it should not. It could involve more complicated logics than what we can imagine to get it done here, although it is not all impossible. If someone would like to layout a detail algorithm here, I believe some parameters in action mappings should be used. But that is easier to create *holes* than ... That's why it is a *difficult* problem :-) Jing (not sure logistically which one has the request signature more importantly which one makes sense)... This is in order: processMultipart processPath processLocale processContent processNoCache processPreProcess * looks promising processMapping processRoles processActionForm processPopulate 1st and 3rd are normally done in the action class. One that handles the display and the one that you are submitting to. sandeep --- Adam Hardy [EMAIL PROTECTED] wrote: I'm sure a quick look in the source code would give you what you want - try looking at isTokenValue() in Action.java Jing Zhou wrote: - Original Message - From: Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED
Re: dificult problem, preventing population (repost)
I'm sure a quick look in the source code would give you what you want - try looking at isTokenValue() in Action.java Jing Zhou wrote: - Original Message - From: Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 6:57 PM Subject: dificult problem, preventing population (repost) I have the following scenario occuring. I have a form with several fields on it (the fields are sourced to a collection in an ActionForm). I have a button that allows the removal of fields from the form (items from the collection). If a user removes a field from the form and then double submits/clicks back and reloads then an exception is thrown from BeanUtils.populate() because it attempts to take details from the (now removed field) and populate it into the object that is stored in the position it was located in the collection. Obviously since the collection is now smaller this results in an IndexOutOfBoundsException. Is there any way to examine the transaction token from the form prior to the form bean being populated and then avoid population of the form bean if the token is not valid? There are three steps involved when using transaction token: 1) Setting token; 2) Checking token; 3) Resetting token; It looks right if we could perform the second step in a subclass of the RequestProcessor so that the token is checked before form bean population. But where do we put the first step and the third step? If we put them in an action class, then how does the derived request processor know when it should check the token? If we put them all in the derived request processor, that is not correct either, because they are business logics not applicable to every action mappings. The real *bad* guy is the browser's Back button your users are using. The browser's tool bar and address bar are intended to help load document oriented resources. They are useless for application oriented resources in our concepts. One good practice I saw is to turn off the tool bar and address bar. It gives you the look and feel of *real* applications. Of course, you must provide navigation buttons for your applications. Sometimes, business people would say they *want* the tool bar or address bar (actually they do not know what really they want in many times :-) In such case, you have to find a way to disable the Back button. If you try the JavaScript location.replace() in the second page, it will forget the past - no back any more. As you see, it is not easy to get a *correct* solution and my suggestion may not be applicable to your case. But I am interested in any further thoughts. Help with this problem would be greatly appreciated. Rob Jing Netspread Carrier http://www.netspread.com - 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: dificult problem, preventing population (repost)
I think he meant isTokenValid(). Also the form tag will create the token and you can look at it in the source. You can check the token higher if you want (before population) by placing it in one of these methods on the requestProcessor.. (not sure logistically which one has the request signature more importantly which one makes sense)... This is in order: processMultipart processPath processLocale processContent processNoCache processPreProcess * looks promising processMapping processRoles processActionForm processPopulate 1st and 3rd are normally done in the action class. One that handles the display and the one that you are submitting to. sandeep --- Adam Hardy [EMAIL PROTECTED] wrote: I'm sure a quick look in the source code would give you what you want - try looking at isTokenValue() in Action.java Jing Zhou wrote: - Original Message - From: Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 6:57 PM Subject: dificult problem, preventing population (repost) I have the following scenario occuring. I have a form with several fields on it (the fields are sourced to a collection in an ActionForm). I have a button that allows the removal of fields from the form (items from the collection). If a user removes a field from the form and then double submits/clicks back and reloads then an exception is thrown from BeanUtils.populate() because it attempts to take details from the (now removed field) and populate it into the object that is stored in the position it was located in the collection. Obviously since the collection is now smaller this results in an IndexOutOfBoundsException. Is there any way to examine the transaction token from the form prior to the form bean being populated and then avoid population of the form bean if the token is not valid? There are three steps involved when using transaction token: 1) Setting token; 2) Checking token; 3) Resetting token; It looks right if we could perform the second step in a subclass of the RequestProcessor so that the token is checked before form bean population. But where do we put the first step and the third step? If we put them in an action class, then how does the derived request processor know when it should check the token? If we put them all in the derived request processor, that is not correct either, because they are business logics not applicable to every action mappings. The real *bad* guy is the browser's Back button your users are using. The browser's tool bar and address bar are intended to help load document oriented resources. They are useless for application oriented resources in our concepts. One good practice I saw is to turn off the tool bar and address bar. It gives you the look and feel of *real* applications. Of course, you must provide navigation buttons for your applications. Sometimes, business people would say they *want* the tool bar or address bar (actually they do not know what really they want in many times :-) In such case, you have to find a way to disable the Back button. If you try the JavaScript location.replace() in the second page, it will forget the past - no back any more. As you see, it is not easy to get a *correct* solution and my suggestion may not be applicable to your case. But I am interested in any further thoughts. Help with this problem would be greatly appreciated. Rob Jing Netspread Carrier http://www.netspread.com - 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] __ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: dificult problem, preventing population (repost)
- Original Message - From: Adam Hardy [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 3:50 AM Subject: Re: dificult problem, preventing population (repost) I'm sure a quick look in the source code would give you what you want - try looking at isTokenValue() in Action.java If I understand the original question correctly, it is too late to check the token using isTokenValid() in action class. Then you have to consider something at an *early* time. Jing Zhou wrote: - Original Message - From: Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 6:57 PM Subject: dificult problem, preventing population (repost) I have the following scenario occuring. I have a form with several fields on it (the fields are sourced to a collection in an ActionForm). I have a button that allows the removal of fields from the form (items from the collection). If a user removes a field from the form and then double submits/clicks back and reloads then an exception is thrown from BeanUtils.populate() because it attempts to take details from the (now removed field) and populate it into the object that is stored in the position it was located in the collection. Obviously since the collection is now smaller this results in an IndexOutOfBoundsException. Is there any way to examine the transaction token from the form prior to the form bean being populated and then avoid population of the form bean if the token is not valid? There are three steps involved when using transaction token: 1) Setting token; 2) Checking token; 3) Resetting token; It looks right if we could perform the second step in a subclass of the RequestProcessor so that the token is checked before form bean population. But where do we put the first step and the third step? If we put them in an action class, then how does the derived request processor know when it should check the token? If we put them all in the derived request processor, that is not correct either, because they are business logics not applicable to every action mappings. The real *bad* guy is the browser's Back button your users are using. The browser's tool bar and address bar are intended to help load document oriented resources. They are useless for application oriented resources in our concepts. One good practice I saw is to turn off the tool bar and address bar. It gives you the look and feel of *real* applications. Of course, you must provide navigation buttons for your applications. Sometimes, business people would say they *want* the tool bar or address bar (actually they do not know what really they want in many times :-) In such case, you have to find a way to disable the Back button. If you try the JavaScript location.replace() in the second page, it will forget the past - no back any more. As you see, it is not easy to get a *correct* solution and my suggestion may not be applicable to your case. But I am interested in any further thoughts. Help with this problem would be greatly appreciated. Rob Jing Netspread Carrier http://www.netspread.com - 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: dificult problem, preventing population (repost)
- Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 7:49 AM Subject: Re: dificult problem, preventing population (repost) I think he meant isTokenValid(). Also the form tag will create the token and you can look at it in the source. You can check the token higher if you want (before population) by placing it in one of these methods on the requestProcessor.. My analysis shows we can't simply check the token at processPreProcess method, as an example. Because the RequestProcessor doesn't known when it should check and when it should not. It could involve more complicated logics than what we can imagine to get it done here, although it is not all impossible. If someone would like to layout a detail algorithm here, I believe some parameters in action mappings should be used. But that is easier to create *holes* than ... That's why it is a *difficult* problem :-) Jing (not sure logistically which one has the request signature more importantly which one makes sense)... This is in order: processMultipart processPath processLocale processContent processNoCache processPreProcess * looks promising processMapping processRoles processActionForm processPopulate 1st and 3rd are normally done in the action class. One that handles the display and the one that you are submitting to. sandeep --- Adam Hardy [EMAIL PROTECTED] wrote: I'm sure a quick look in the source code would give you what you want - try looking at isTokenValue() in Action.java Jing Zhou wrote: - Original Message - From: Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 6:57 PM Subject: dificult problem, preventing population (repost) I have the following scenario occuring. I have a form with several fields on it (the fields are sourced to a collection in an ActionForm). I have a button that allows the removal of fields from the form (items from the collection). If a user removes a field from the form and then double submits/clicks back and reloads then an exception is thrown from BeanUtils.populate() because it attempts to take details from the (now removed field) and populate it into the object that is stored in the position it was located in the collection. Obviously since the collection is now smaller this results in an IndexOutOfBoundsException. Is there any way to examine the transaction token from the form prior to the form bean being populated and then avoid population of the form bean if the token is not valid? There are three steps involved when using transaction token: 1) Setting token; 2) Checking token; 3) Resetting token; It looks right if we could perform the second step in a subclass of the RequestProcessor so that the token is checked before form bean population. But where do we put the first step and the third step? If we put them in an action class, then how does the derived request processor know when it should check the token? If we put them all in the derived request processor, that is not correct either, because they are business logics not applicable to every action mappings. The real *bad* guy is the browser's Back button your users are using. The browser's tool bar and address bar are intended to help load document oriented resources. They are useless for application oriented resources in our concepts. One good practice I saw is to turn off the tool bar and address bar. It gives you the look and feel of *real* applications. Of course, you must provide navigation buttons for your applications. Sometimes, business people would say they *want* the tool bar or address bar (actually they do not know what really they want in many times :-) In such case, you have to find a way to disable the Back button. If you try the JavaScript location.replace() in the second page, it will forget the past - no back any more. As you see, it is not easy to get a *correct* solution and my suggestion may not be applicable to your case. But I am interested in any further thoughts. Help with this problem would be greatly appreciated. Rob Jing Netspread Carrier http://www.netspread.com - 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
Re: dificult problem, preventing population (repost)
Ah... I see what you mean. Yes, not thinking that clearly, but I have not done it either so that is my excuse... So I think that to make this too complicated is not good. So the original problem states that when pressing the back button that they get back to the screen. I am wondering right now that when the press the back button they should be in the submit state again and the token check should occur again? Sometimes I wish I could pick up the phone and sort these type of things out because I'm probably missing something again. sandeep --- Jing Zhou [EMAIL PROTECTED] wrote: - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 7:49 AM Subject: Re: dificult problem, preventing population (repost) I think he meant isTokenValid(). Also the form tag will create the token and you can look at it in the source. You can check the token higher if you want (before population) by placing it in one of these methods on the requestProcessor.. My analysis shows we can't simply check the token at processPreProcess method, as an example. Because the RequestProcessor doesn't known when it should check and when it should not. It could involve more complicated logics than what we can imagine to get it done here, although it is not all impossible. If someone would like to layout a detail algorithm here, I believe some parameters in action mappings should be used. But that is easier to create *holes* than ... That's why it is a *difficult* problem :-) Jing (not sure logistically which one has the request signature more importantly which one makes sense)... This is in order: processMultipart processPath processLocale processContent processNoCache processPreProcess * looks promising processMapping processRoles processActionForm processPopulate 1st and 3rd are normally done in the action class. One that handles the display and the one that you are submitting to. sandeep --- Adam Hardy [EMAIL PROTECTED] wrote: I'm sure a quick look in the source code would give you what you want - try looking at isTokenValue() in Action.java Jing Zhou wrote: - Original Message - From: Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 6:57 PM Subject: dificult problem, preventing population (repost) I have the following scenario occuring. I have a form with several fields on it (the fields are sourced to a collection in an ActionForm). I have a button that allows the removal of fields from the form (items from the collection). If a user removes a field from the form and then double submits/clicks back and reloads then an exception is thrown from BeanUtils.populate() because it attempts to take details from the (now removed field) and populate it into the object that is stored in the position it was located in the collection. Obviously since the collection is now smaller this results in an IndexOutOfBoundsException. Is there any way to examine the transaction token from the form prior to the form bean being populated and then avoid population of the form bean if the token is not valid? There are three steps involved when using transaction token: 1) Setting token; 2) Checking token; 3) Resetting token; It looks right if we could perform the second step in a subclass of the RequestProcessor so that the token is checked before form bean population. But where do we put the first step and the third step? If we put them in an action class, then how does the derived request processor know when it should check the token? If we put them all in the derived request processor, that is not correct either, because they are business logics not applicable to every action mappings. The real *bad* guy is the browser's Back button your users are using. The browser's tool bar and address bar are intended to help load document oriented resources. They are useless for application oriented resources in our concepts. One good practice I saw is to turn off the tool bar and address bar. It gives you the look and feel of *real* applications. Of course, you must provide navigation buttons for your applications. Sometimes, business people would say they *want* the tool bar or address bar (actually they do not know what really they want in many times :-) In such case, you have to find a way to disable the Back button. If you try the JavaScript location.replace() in the second page, it will forget the past - no back any more. As you see, it is not easy to get
Re: dificult problem, preventing population (repost)
Hi, Sandeep, There is no clean solution to this problem, not only in Struts but also in many others ... I wish there could be a simple way to disable the Back button. But browser vendors would say once it is disabled, who is responsible to enable it. There should be some better algorithm for this problem. Jing - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED]; Jing Zhou [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 12:35 PM Subject: Re: dificult problem, preventing population (repost) Ah... I see what you mean. Yes, not thinking that clearly, but I have not done it either so that is my excuse... So I think that to make this too complicated is not good. So the original problem states that when pressing the back button that they get back to the screen. I am wondering right now that when the press the back button they should be in the submit state again and the token check should occur again? If the previous page is a submitted page, you would get Page has Expired If the previous page is retrieved by an http get method, you would do a GET again. Sometimes I wish I could pick up the phone and sort these type of things out because I'm probably missing something again. sandeep --- Jing Zhou [EMAIL PROTECTED] wrote: - Original Message - From: Sandeep Takhar [EMAIL PROTECTED] To: Struts Users Mailing List [EMAIL PROTECTED] Sent: Thursday, July 17, 2003 7:49 AM Subject: Re: dificult problem, preventing population (repost) I think he meant isTokenValid(). Also the form tag will create the token and you can look at it in the source. You can check the token higher if you want (before population) by placing it in one of these methods on the requestProcessor.. My analysis shows we can't simply check the token at processPreProcess method, as an example. Because the RequestProcessor doesn't known when it should check and when it should not. It could involve more complicated logics than what we can imagine to get it done here, although it is not all impossible. If someone would like to layout a detail algorithm here, I believe some parameters in action mappings should be used. But that is easier to create *holes* than ... That's why it is a *difficult* problem :-) Jing (not sure logistically which one has the request signature more importantly which one makes sense)... This is in order: processMultipart processPath processLocale processContent processNoCache processPreProcess * looks promising processMapping processRoles processActionForm processPopulate 1st and 3rd are normally done in the action class. One that handles the display and the one that you are submitting to. sandeep --- Adam Hardy [EMAIL PROTECTED] wrote: I'm sure a quick look in the source code would give you what you want - try looking at isTokenValue() in Action.java Jing Zhou wrote: - Original Message - From: Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 6:57 PM Subject: dificult problem, preventing population (repost) I have the following scenario occuring. I have a form with several fields on it (the fields are sourced to a collection in an ActionForm). I have a button that allows the removal of fields from the form (items from the collection). If a user removes a field from the form and then double submits/clicks back and reloads then an exception is thrown from BeanUtils.populate() because it attempts to take details from the (now removed field) and populate it into the object that is stored in the position it was located in the collection. Obviously since the collection is now smaller this results in an IndexOutOfBoundsException. Is there any way to examine the transaction token from the form prior to the form bean being populated and then avoid population of the form bean if the token is not valid? There are three steps involved when using transaction token: 1) Setting token; 2) Checking token; 3) Resetting token; It looks right if we could perform the second step in a subclass of the RequestProcessor so that the token is checked before form bean population. But where do we put the first step and the third step? If we put them in an action class, then how does the derived request processor know when it should check the token? If we put them all in the derived request processor, that is not correct either, because they are business logics not applicable to every action mappings. The real *bad* guy is the browser's
Re: dificult problem, preventing population (repost)
- Original Message - From: Rob [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Wednesday, July 16, 2003 6:57 PM Subject: dificult problem, preventing population (repost) I have the following scenario occuring. I have a form with several fields on it (the fields are sourced to a collection in an ActionForm). I have a button that allows the removal of fields from the form (items from the collection). If a user removes a field from the form and then double submits/clicks back and reloads then an exception is thrown from BeanUtils.populate() because it attempts to take details from the (now removed field) and populate it into the object that is stored in the position it was located in the collection. Obviously since the collection is now smaller this results in an IndexOutOfBoundsException. Is there any way to examine the transaction token from the form prior to the form bean being populated and then avoid population of the form bean if the token is not valid? There are three steps involved when using transaction token: 1) Setting token; 2) Checking token; 3) Resetting token; It looks right if we could perform the second step in a subclass of the RequestProcessor so that the token is checked before form bean population. But where do we put the first step and the third step? If we put them in an action class, then how does the derived request processor know when it should check the token? If we put them all in the derived request processor, that is not correct either, because they are business logics not applicable to every action mappings. The real *bad* guy is the browser's Back button your users are using. The browser's tool bar and address bar are intended to help load document oriented resources. They are useless for application oriented resources in our concepts. One good practice I saw is to turn off the tool bar and address bar. It gives you the look and feel of *real* applications. Of course, you must provide navigation buttons for your applications. Sometimes, business people would say they *want* the tool bar or address bar (actually they do not know what really they want in many times :-) In such case, you have to find a way to disable the Back button. If you try the JavaScript location.replace() in the second page, it will forget the past - no back any more. As you see, it is not easy to get a *correct* solution and my suggestion may not be applicable to your case. But I am interested in any further thoughts. Help with this problem would be greatly appreciated. Rob Jing Netspread Carrier http://www.netspread.com - 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]
