I'm not even sure there is a problem. I have a complicated multi-page survey and on one page there is a table with multiple rows where each row is a separate object. You can add new blank rows and delete rows. To make it all more complicated, each field updates the database using AJAX onChange or onBlur.
One of the beta testers backed up to this page and the ajax row device failed, which caused all the scripts to shut down, which was a complete disaster since nothing was being updated (and there is no submit button). I have not been able to duplicate this, and since this survey is only for two weeks and a few dozen people, I may just ask them to avoid the back button. But I was considering expiring pages so that when you backed up it forced a reload of the page (after that everything works fine). Does this make any sense? (Oh, and just to complicate things a bit more, I'm passing the survey back and forth in the URL via a guid, so it's more like /page_one/xxxxx, /page_two/xxxxx, etc. I make a hit on the database and reload the survey via a JPA query each time just to be sure I have the most up-to-date copy, and also so the users can link to the survey pages and come back to them later.) Chas. Tim Perrett wrote: > Chas, > > Can you detail exactly what the problem is when a user backs up? Do > you have URLs like: > > /questions-one > /questions-two > /questions-three > > etc? > > Users using the back button is a common problem faced by web-dev's the > world over. Id be interested to hear exactly what your problem is and > how using cache headers will help you? > > IMO, cache headers like ETag and Cache-Control have a specific use and > im not sure they are the right solution for your problem. For > instance, I might use the caching headers as part of a conditional get > strategy in a rest api... > > Cheers > > Tim > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Lift" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/liftweb?hl=en -~----------~----~----~----~------~----~------~--~---
