If that list is changing, in the sense of new items added or existing items removed, and that list is part of a form, then you're likely to run into rewind problems in the sense that the rewind mechanism will discover your data is stale. Whether the stale data is a problem depends on how you position the tradeoff between user inconvenience and data integrity.
The database analogy concerns the risk of lost updates to a particular record - so clearly when the problem arises, you need to address it in favour of data integrity rather than user convenience.
I'd argue that the Tapestry rewind process can over-favour data integrity at the expense of the end users. Why? Because if your list is changing more than a few times a minute, then a stale form between requests is quite likely. Suppose the list on average contains 20 items. Then for every item change there is only 1/20 chance that the change would actually affect the item the user is interested in. Stale data would only really be a problem from the users point of view if the record you are interested in is deleted. Of course, without rewind, the application would need to pick this up, which it should be doing gracefully anway.
Even with rewind, you still need database versioning to maintain the integrity of individual records. The rewind process in general does not help with this.
Mark Stang wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
