Mark,
I've shipped apps that used an approach like you're describing e.g. keep
state in the session and "break" if the user had the audacity to use the
back button. To say they performed poorly in the market is overly kind; I
damn near got lynched at user conferences.
For better or for worse, the web is an inherently stateless system. We can
try to add our own statefulness system onto of HTTP, but we have to do so in
a way that is transparent to the users. Users *expect* to be able to hit
back twice and select a different camera off the list of cameras and have
the system just work. Telling a user that behavior won't work is like
telling a user of a word processor that your new version is way better than
the old one because you removed UNDO.
Statelessness definitely does create locking issues as you identify below as
it basically forces you into a permissive locking scheme and can absolutely
result in the user returning stale transactions e.g. operating on a stale
record. A stateless system means that I as a developer have to defense
against this in my code which is more work for me. Whereas in a stateful
system I could use more aggressive locking and not have to worry about the
error case.
It basically comes down to user expectation. Users *expect* to be able to
use the back button. Their entire life history with web applications has
trained them to work that way. To try to break them of that habit is like
trying to stop the tide rising (not to mention a sure-fire way to guarantee
you sell no copies of your app).
-- Pat
> -----Original Message-----
> From: Mark Stang [mailto:[EMAIL PROTECTED]
> Sent: Friday, May 06, 2005 2:41 PM
> To: Tapestry users Howard Lewis Ship; Tapestry users; Michael Musson
> Subject: RE: As a User, which two items would you personally most like to
> see in the next Tapestry Release?
>
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
