Can someone please explain me why is highly recommended to use Django forms to get an html object instead of direct accessing from request.POST or request.GET?
Can someone please explain me why is highly recommended to use Django forms to get an html object instead of direct accessing from request.POST or request.GET?
In short: forms make retrieving and validating less error-prone, and often will perform a lot of logic that would otherwise require (a lot of) boilerplate code.
The items in request.POST (or request.GET) are send by the browser, so you can in no way guarantee that the items will (all) be present, and in the expected format.
Indeed, request.POST['somefield'] can raise a KeyError in case the POST request does not contain an key-value pair with somefield as key. Of course you can wrap this in a try … except …, but that easily will generate a large amount of code for a form with multiple items.
Even if the item is present in the request.POST, it is not per see in the expected format. For example if you use a number field (<input name="somefield" type="number">), you expect a number. But one can easily "forge" a HTTP request, where somefield contains 'blabla' or 'forty-two' instead. Django can validate the format of the fields. For an IntegerField [Django-doc] for example, it will require the value to be an optional minus sign followed by a sequence of digits.
A Django form will also "clean" the values. THis means that if you use an IntegerField, and later you access form.cleaned_data['somefield'], it will not have as type a string, but an int. You thus do not have to do the conversion yourself explicitly. This means that you can immediately add the values of two IntegerFields together for example, whereas if you do it yourself, these are first strings, and adding these together would concatenate the strings.
If cleaning or validating somehow fails, and a field contains an error, then a Form can explain what the error(s) are. You can access form.errors, which is a dictionary-like object that maps the names of the fields to a list of problems. It also makes it more convenient to list multiple errors. For example if a password should be at least 10 characters, and contain an uppercase, you can report both problems.
A ModelForm [Django-doc] also makes creating and updating an object more convenient. It has a .save() method for that. This thus will create a new record at the database in case the .instance wrapped in it was not yet saved, or update the record otherwise. It furthermore also will save ManyToManyFields (at least if you do not set commit=False). This is a tricky task since in order to save the objects in the many-to-many relations, you first need to create the object at the database side.
Finally you can also use a form to easily render it at the HTML side. There are Django apps like django-crispy-forms [GitHub] that can give the form another look. It thus makes it convenient to render the form, and easily change the appearance if you change your mind.