> > In my opinion, trying to abstract that stuff away in a web application > > causes to more problems than it solves, especially where back buttons and > > bookmarks are concerned. > > We haven't found this to be the case. Our servers are sessionless, > so bookmarks work fine.
These are different (though related) concepts. The original poster was looking for a way to structure web programs without thinking about the breaks caused by the request model of HTTP, and that's what I was commenting on. You're talking about a way to preserve data across multiple page requests. > > I think it's easier to take a state machine > > approach, the way CGI::MxScreen or Apache::PageKit do. > > I don't think this works. The state machine can manage states going > forward, but not backward. You can code a state machine that defines legal transitions from one state to another, and that could include stepping "backward". There's no real concept of forward and backward in what I had in mind, just a collection of states and legal transitions between them. If you hit the back button, you're still okay as long as the form's data is stored in the URL or hidden fields rather than in a global session, i.e. going back will return you to the state you were in correctly. Most people instinctively code a state machine when they start using CGI, but they do it in the form of a bunch of statements like "if $form_action eq 'save'". The frameworks I mentioned just pull it out and make it more explicit. If I understand your FormContext approach correctly, you are storing the state of the current application in URLs or hidden fields. This is what we used at eToys as well, and I think it's a pretty common solution. It's the only way to safely handle possibilities like multiple browser windows using the same application. There are some CPAN modules that help with this kind of thing, like CGI::EncryptForm. - Perrin
