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 [email protected].
To post to this group, send email to [email protected].
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/30ec5eed-d7ef-40df-8827-b59154088383%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
