Thursday, November 28, 2013

Re: GET and POST in forms. Please help me understand the logic!

Awesome I feel much better about this now. Thanks for your help!

On Thursday, 28 November 2013 09:29:05 UTC, Daniel Roseman wrote:
On Thursday, 28 November 2013 03:24:11 UTC, Andrew Taylor wrote:
Hi,

I'm struggling with the concepts of get and post and where these status come from in the workflow. I have worked my way through the official pages on forms but I have not quite understood this to my satisfaction.

I get the gist that:
  • get is for requesting data and 
  • the query string parameters are visible 
  • Running multiple get operations with say a bookmarked link has no negative effect
whereas with post
  • post is for making database changes
Beyond this I am a little clueless.
  • When does a request method get assigned? 
  • In other words, with this code below, what would have made the request method become post (or get)? Is this related to a preceding view?
  • Does a request object have to have a get or a post dictionary in it? Could it have neither?
  • Does a request object going to a form have to have a get or a post dictionary in it?
  • Is it the case that with "add_category.html" the page could open with neither a get or post in the request, and while the "add_category" view is running the request method POST could be assigned?
  • Does a POST method invoke form validation?

Example:

def add_category(request, category_name_url=""):
    context = RequestContext(request)

    if request.method == 'POST':
        form = CategoryForm(request.POST)

        if form.is_valid():
            form.save(commit=True)
            return index(request)
        else:
            print form.errors

    else:
        form = CategoryForm


    return render_to_response('rango/add_category.html', {'form': form}, context)


Thanks,


Andy



This isn't really anything to do with Django, but the general semantics of the web.

*All* requests have a verb associated with them, and most of the time that verb is GET: basically, your browser is requesting that the server give them a page from the given address. That address might include a querystring, which servers parse into GET parameters, or it might not. Again, the generally accepted use of the querystring is that it in some way affects the document that is returned - for example, requesting a specific page in a paginated set - rather than modifying something on the server itself.

When you want to send information from your browser to the server, you would mostly use POST. Most of the time, that is done by sending a form. But note that it is the HTML that determines this: your form tag has an `method` parameter, which is either GET or POST,  and when you click submit the information is sent with the specified method to the URL given in the `action` parameter:
<form action="/my/url/" method="POST">
Again, note that it is perfectly valid to use GET here, for example in a form that specifies values to be used in a search - because you're affecting what is returned to you, but not changing anything on the server. But a registration form, or a form where you enter your CMS content for posting, would always be POST.

Now in Django, we have settled on a particular pattern, which works like this:
* Browser requests the page, ie GET.
* Server returns the form to be filled in (possibly pre-populated with data).
* Form is sent back via POST to the *same URL*.
* In the view, execution enters the `if request.method=="POST"` block and therefore invokes form validation.
* Server either returns invalid form (with errors) or saves the content and redirects (via GET) to another URL.

(Not to confuse you, but HTTP supports other verbs too, including PUT and DELETE, but these are used mainly in REST and can't usually be generated by browsers.)

Hope this helps.
--
DR.

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/9d5106e5-83c5-4e2d-958a-6bdfe6ed5da0%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

No comments:

Post a Comment