On Jan 19, 2011, at 7:15 AM, Anthony wrote: > On Wednesday, January 19, 2011 1:35:09 AM UTC-5, Jonathan Lundell wrote: > Actually, there's a bug in the documentation (or else in Session). You have > to say: > > session.forget(response) > > or else the session doesn't get unlocked > > There are at least four occurrences of session.forget() in the book, and one > in the 'call' action in the default.py controller of the 'welcome' app. > Should all of those be replaced with session.forget(response)? Is there any > reason to use session.forget() with the default response=None (which sets > session._forget=True but does not unlock the session file)? If not, maybe the > default behavior of session.forget() itself should be changed.
This belated reply might be redundant, but never mind... I don't think we want to change the default behavior of session.forget(), because it might break existing applications. At the very least, they haven't been tested in the unlock-session mode if they're calling session.forget() without an argument. The book's mention of session.forget isn't actually wrong: The session object has two important methods. One is forget: 1. session.forget() It tells web2py not to save the session. This should be used in those controllers whose actions are called often and do not need to track user activity. That's actually true. What we need is another paragraph to document session.forget(response), explaining that it disables session serialization. For most apps, there's probably not much need to do this. I have an app that dynamically generates its main css file, and it would be useful for that not to have to wait for the main page to finish loading, but even there the css file will ordinarily be cached by the browser, so it doesn't make much difference.
