Which is wrong in so many ways... We are doing this backwards! The session is what must be considered current not the request. If I store state in request and then delete something in another request, when the first request returns data is missing, bad things happen!
Ignore the request if it doesn't match the current state of the session. Rewind does a very nice job. The very first time it finds something out of sync, it tosses you out and quits trying to do the rewind. I need to make it more robust so that I can detect the rewind at the beginning before bad things happen. I suspect there is a way to fool it by using the same screen and changing it so it "matches" the rewind, but screws up the data. Right now my screens are so different that the rewind bails on finding mis-matched fields, which is a good thing. Detect that the user has done something wrong, warn them and move on! I think Howard should put in a "token" that changes with every screen randomly and if it doesn't match what is happening, then throw them out!!! This is a common technique with databases. When you save data, put in a timestamp. When it comes time to update the same data, if the timestamp doesn't match, then they don't have the current data, throw them out! Now databases have a nicer interface, they can override the timestamp and force it to save it anyway. Of course, other rows and your entire data model might get out of sync if they did that! What we have here is last one in wins, all others are rejected! Tapestry has a good start on that process. regards, Mark -----Original Message----- From: Howard Lewis Ship [mailto:[EMAIL PROTECTED] Sent: Fri 5/6/2005 12:55 PM To: Tapestry users; Michael Musson Subject: Re: As a User, which two items would you personally most like to see in the next Tapestry Release? Yes, and persistent properties on the client help ensure that the appllication state stays associated with the request not the session. On 5/6/05, Michael Musson <[EMAIL PROTECTED]> wrote: > > One example like what I think Patrick is saying is the evil browser > back button. One benefit of pushing persistence to the form like .NET > is that the "context" stays in sync with the browser (ie. I go back to > a previous version of the page (now stale) but the embeded context is > also stale (consistent with the page). > > On May 6, 2005, at 1:30 PM, Patrick Casey wrote: > > Just curious: can you come up with a case when you will get a stale > > link > > problem if you use If and For instead of Foreach, etc? > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > -- Howard M. Lewis Ship Independent J2EE / Open-Source Java Consultant Creator, Jakarta Tapestry Creator, Jakarta HiveMind Professional Tapestry training, mentoring, support and project work. http://howardlewisship.com
