On Tue, Jul 1, 2008 at 6:10 PM, Waylan Limberg <[EMAIL PROTECTED]> wrote: > Um, this is intentional and a good thing. If you read the spec, not > only is the difference between GET and POST defined, but the way user > agents (browsers) should treat them is defined as well. Breaking the > back & reload buttons is a requirement of the spec to, among other > reasons, avoid multiple posts by impatient (or double-clicking) users. > Granted, browsers could provide more helpful messages, but we want > that behavior for POSTing data.
Keep in mind that your average user doesn't care what a spec says about HTTP. I know the spec (well enough) and I agree that a browser should not allow people to accidentally POST by refreshing the page. That is the whole point of POSTing where it's needed (substantial amounts of form data or something that changes the state of the system), and redirect to GET the next page, since retrieving the next page should not be a problem regardless of how many times you do that. Anyway, a lot of users don't understand what the POST warning is about, and they'll rePOST anyway. If you POST then redirect to GET, you remove the POST from their history and don't (necessarily) have to worry about them POSTing by mistake. Clicking back to GET the previous page (perhaps from cache) should not be a problem either, and if it is, we can do better than a confusing browser confirmation dialog. (set the expiry policy properly and use the session scope to detect a problem and provide instructions to the user) > Perhaps he wants to allow the user to stop part way through a wizard, > bookmark the url (with the data entered thus far preserved in the > querystring), and allow them to pick up where they left off later.? > Interesting, but I wouldn't recommend it. For one, that could result > in some long urls (perhaps even longer than the limit). A multi-part > form could add up to a lot pretty quick. Second, those would be some > ugly urls. And third, as mentioned above, it's not really the proper > use of GET anyway. Well, the encoding multiple pages of form values in the URL is going to be problematic because of the issue I mentioned where servers will not work with ridiculously long URLs. My thinking is this is a case where using the session scope is valuable. I'm honestly a django newbie so I can't say much about the problems of storing forms in session scope. You could easily store some object, even just a dictionary or sequence of dictionaries representing the wizard state somewhere else and populate the form values on the GET pageX request. Session is handy but also storing elsewhere in case someone's session times out or they want to bookmark is nice. > So, unless a strong use-case is provided, I'm -1 on this. There's definitely a strong use-case for mere form display to be a GET not a POST. This is web-wizards 101. Believe me, I've written some wizards. -Dave --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
