Skip to content

Django forms: POST vs GET explanation #1864

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Mar 11, 2025
Merged

Django forms: POST vs GET explanation #1864

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion en/django_forms/README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -189,7 +189,7 @@ def post_new(request):
return render(request, 'blog/post_edit.html', {'form': form})
```

When we submit the form, we are brought back to the same view, but this time we have some more data in `request`, more specifically in `request.POST` (the naming has nothing to do with a blog "post"; it's to do with the fact that we're "posting" data). Remember how in the HTML file, our `<form>` definition had the variable `method="POST"`? All the fields from the form are now in `request.POST`. You should not rename `POST` to anything else (the only other valid value for `method` is `GET`, but we have no time to explain what the difference is).
When we submit the form, we are brought back to the same view, but this time the `request` parameter is different. If we look at the `request.method` it will be `"POST"` (method for sending forms) instead of `"GET"` (method for requesting pages) and the `request.POST` field will contain all the fields form the form. The naming has nothing to do with a blog "post"; it's to do with the fact that we're "posting" data.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is request.POST a "field"? I think Python calls instance members "attributes" (see the chapter on classes in the tutorial in the official Python documentation), not "fields" as e.g. Java does.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
When we submit the form, we are brought back to the same view, but this time the `request` parameter is different. If we look at the `request.method` it will be `"POST"` (method for sending forms) instead of `"GET"` (method for requesting pages) and the `request.POST` field will contain all the fields form the form. The naming has nothing to do with a blog "post"; it's to do with the fact that we're "posting" data.
When we submit the form, we are brought back to the same view, but this time the `request` parameter is different. If we look at the `request.method` it will be `"POST"` (method for sending forms) instead of `"GET"` (method for requesting pages) and the `request.POST` field will contain all the fields from the form. The naming has nothing to do with a blog "post"; it's to do with the fact that we're "posting" data.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is request.POST a "field"? I think Python calls instance members "attributes" (see the chapter on classes in the tutorial in the official Python documentation), not "fields" as e.g. Java does.

(Also, "field" is already used for the special attributes in Django models that represent database table columns, as well (in this very sentence) for form fields, so we'd better avoid introducing it with yet another meaning.)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are absolutely right, the word attribute is better. Since this pull request is already merged and closed I created another one #1866 that fixes what you pointed out.


So in our *view* we have two separate situations to handle: first, when we access the page for the first time and we want a blank form, and second, when we go back to the *view* with all form data we just typed. So we need to add a condition (we will use `if` for that):

Expand Down