> For the complete documentation index, see [llms.txt](https://ricardomol.gitbook.io/notes/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://ricardomol.gitbook.io/notes/backend/django.md). # Django ## Key features * Admin Interface (CRUD) * Templating * Form handling * Internationalization * Session, user management, role-based permissions * Object-relational mapping (ORM) * Testing Framework * Fantastic Documentation ## Architecture * **Models:** It describes your database schema and your data structure * **Views:** It controls what a user sees, the view retrieves data from appropriate models and execute any calculation made to the data and pass it to the template * **Templates:** It determines how the user sees it. It describes how the data received from the views should be changed or formatted for display on the page * **Controller:** The Django framework and URL parsing ## MVC Django closely follows the **MVC (Model View Controller)** design pattern, however, it does use its own logic in the implementation. Because the **“C” is handled by the framework itself and most of the excitement in Django happens in models, templates, and views**, Django is often referred to as an **MTV** framework. In the MTV development pattern: * **Model: the data access layer.** Contains anything and everything about the data: how to access it, how to validate it, which behaviors it has, and the relationships between the data. * **Template: the presentation layer**. Contains presentation-related decisions: how something should be displayed on a Web page or other type of document. * **View: the business logic layer**. Contains the logic that accesses the model and defers to the appropriate template(s). You can think of it as the bridge between models and templates. Further reading: ## **Requests processing** Whenever a request is made by a user, it goes through the following steps: * Django determines the root URLconf module to use. Ordinarily, this is the value of the ROOT\_URLCONF setting, but if the incoming HttpRequest object has a **urlconf** attribute (set by middleware), its value will be used in place of the **ROOT\_URLCONF** setting. * Django loads that Python module and looks for the variable urlpatterns. This should be a Python list of **django.urls.path()**and/or **django.urls.re\_path()** instances. * Django runs through each URL pattern, in order, and stops at the first one that matches the requested URL. * Once one of the URL patterns matches, Django imports and calls the given view, which is a simple Python function (or a class-based view). The view gets passed the following arguments: * An instance of HttpRequest. * If the matched URL pattern returned no named groups, then the matches from the regular expression are provided as positional arguments. * The keyword arguments are made up of any named parts matched by the path expression, overridden by any arguments specified in the optional kwargs argument to **django.urls.path()** or **django.urls.re\_path()**. * If no URL pattern matches, or if an exception is raised during any point in this process, Django invokes an appropriate error-handling view. ## **Inheritance styles in Django** In Django, there are 3 possible inheritance styles * **Abstract base classes:** When you only wants parent’s class to hold information that you don’t want to type out for each child model * **Multi-table Inheritance:** If you are sub-classing an existing model and need each model to have its own database table * **Proxy models:** When you only want to modify the Python level behavior of the model, without changing the model’s fields ## Signals Allow to execute some piece of code based on some action or event occurred in the framework. Ex.: new user register, on delete of a record. Some inbuilt signals in Django: * pre\_save and post\_save. * pre\_delete and post\_delete * pre\_request and post\_request * pre\_request and post\_request ## Middleware **Function that acts on or transforms a request/response before/after it passes through the view** layer. Each middleware component is responsible for doing some specific function. Example: Django includes a middleware component, [`AuthenticationMiddleware`](https://docs.djangoproject.com/en/2.1/ref/middleware/#django.contrib.auth.middleware.AuthenticationMiddleware), that associates users with requests using sessions. \ Some usage of middlewares in Django is: * It can be used for Session management, * User authentication can be done with the help of this. * It helps in Cross-site request forgery protection * Content Gzipping, etc. ### Middleware order and layering **During the request phase, before calling the view, Django applies middleware in the order it’s defined in** [**`MIDDLEWARE`**](https://docs.djangoproject.com/en/2.1/ref/settings/#std:setting-MIDDLEWARE)**, top-down**. If one of the layers decides to short-circuit and return a response without ever calling its `get_response`, none of the layers of the onion inside that layer (including the view) will see the request or the response. The response will only return through the same layers that the request passed in through. ## Sessions ### Intro All communication between web browsers and servers is via the **HTTP** protocol, which is ***stateless***. Ie., **messages between the client and server are completely independent of each other— there is no notion of "sequence"** or behavior based on previous messages. As a result, if you want to have a site that keeps track of the ongoing relationships with a client, you need to implement that yourself. ### Definition Sessions are the **mechanism for keeping track of the "state" between the site and a particular browser**. Sessions **allow you to store arbitrary data per browser**, and have this data available to the site whenever the browser connects. Individual data items associated with the session are then referenced by a "key", which is used both to store and retrieve the data. **Django uses a cookie containing a special *****session id***** to identify each browser and its associated session with the site**. The actual session *data* is stored in the site database by default (this is more secure than storing the data in a cookie, where they are more vulnerable to malicious users). ### Enabling sessions Edit `INSTALLED_APPS` and `MIDDLEWARE` sections of the project file (**foo/foo/settings.py**): ``` INSTALLED_APPS = [ ... 'django.contrib.sessions', .... MIDDLEWARE = [ ... 'django.contrib.sessions.middleware.SessionMiddleware', .... ``` ### Using sessions Access the `session` attribute in the view from the `request` parameter (an `HttpRequest` passed in as the first argument to the view). This **session attribute represents the specific connection to the current user (or to be more precise, the connection to the current *****browser*****, as identified by the session id in the browser's cookie for this site)**. The **`session` attribute is a dictionary-like object that you can read and write as many times as you like in your view, modifying it as wished**. You can do all the normal dictionary operations, including clearing all data, testing if a key is present, looping through data, etc. Most of the time though, you'll just use the standard "dictionary" API to get and set values. Example: ``` # Get a session value by its key (e.g. 'my_car'), raising a KeyError if the key is not present my_car = request.session['my_car'] # Get a session value, setting a default if it is not present ('mini') my_car = request.session.get('my_car', 'mini') # Set a session value request.session['my_car'] = 'mini' # Delete a session value del request.session['my_car'] ``` ### Saving session data By default, **Django only saves to the session database and sends the session cookie to the client when the session has been *****modified***** (assigned) or *****deleted***. Example: ``` # This is detected as an update to the session, so session data is saved. request.session['my_car'] = 'mini' ``` If you're **updating some information *****within***** session data**, then Django will not recognize that you've made a change to the session and save the data. In this case you will need to **explicitly mark the session as having been modified:** ``` # Session object not directly modified, only data within the session. Session changes not saved! request.session['my_car']['wheels'] = 'alloy' # Set session as modified to force data updates/cookie to be saved. request.session.modified = True ``` **Note**: You can change the behavior so the site will update the database/send cookie on every request by adding `SESSION_SAVE_EVERY_REQUEST = True` ## Views A **callable which takes a request and returns a response**. ## Base vs Generic views **Base class-based views** can be thought of as *parent* views, which can be used by themselves or inherited from. They may not provide all the capabilities required for projects, in which case there are Mixins which extend what base views can do. Django’s **generic views** are built off of those base views, and were developed as a shortcut for common usage patterns such as displaying the details of an object. They take certain common idioms and patterns found in view development and abstract them so that you can quickly write common views of data without having to repeat yourself. Most generic views require the `queryset` key, which is a `QuerySet` instance; see [Making queries](https://docs.djangoproject.com/en/2.1/topics/db/queries/) for more information about `QuerySet` objects. ## Class-based Views Provide an alternative way to implement views as Python objects instead of functions. They do not replace function-based views. Differences and advantages when compared to **function-based views**: * **Organization of code related to specific HTTP methods** (`GET`, `POST`, etc.) can be addressed by separate methods instead of conditional branching. * **Object oriented techniques** such as mixins (multiple inheritance) can be used to factor code into reusable components. ### Using class-based views A class-based view allows you to respond to different HTTP request methods with different class instance methods, instead of with conditionally branching code inside a single view function. Handle HTTP `GET` in a **view function**: ``` from django.http import HttpResponse def my_view(request): if request.method == 'GET': # return HttpResponse('result') ``` In a **class-based view**: ``` from django.http import HttpResponse from django.views import View class MyView(View): def get(self, request): # return HttpResponse('result') ``` Django’s URL resolver expects to send the request and associated arguments to a callable function, not a class, therefore **class-based views have an** [**`as_view()`**](https://docs.djangoproject.com/en/2.1/ref/class-based-views/base/#django.views.generic.base.View.as_view) . ``` # urls.py from django.urls import path from myapp.views import MyView urlpatterns = [ path('about/', MyView.as_view()), ] ``` You can configure class attributes as keyword arguments to the [`as_view()`](https://docs.djangoproject.com/en/2.1/ref/class-based-views/base/#django.views.generic.base.View.as_view) call in the URLconf: ``` urlpatterns = [ path('about/', GreetingView.as_view(greeting="G'day")), ] ``` `dispatch` looks at the request to determine whether it is a `GET`, `POST`, etc, and relays the request to a matching method if one is defined, or raises [`HttpResponseNotAllowed`](https://docs.djangoproject.com/en/2.1/ref/request-response/#django.http.HttpResponseNotAllowed) ### Decorating the class To decorate every instance of a class-based view, you need to decorate the class definition itself. To do this you apply the decorator to the [`dispatch()`](https://docs.djangoproject.com/en/2.1/ref/class-based-views/base/#django.views.generic.base.View.dispatch) method of the class. A method on a class isn’t quite the same as a standalone function, so you can’t just apply a function decorator to the method – you need to transform it into a method decorator first. The `method_decorator` decorator transforms a function decorator into a method decorator so that it can be used on an instance method. For example: ``` from django.contrib.auth.decorators import login_required from django.utils.decorators import method_decorator from django.views.generic import TemplateView class ProtectedView(TemplateView): template_name = 'secret.html' @method_decorator(login_required) def dispatch(self, *args, **kwargs): return super().dispatch(*args, **kwargs) ``` Or, more succinctly, you can decorate the class instead and pass the name of the method to be decorated as the keyword argument `name`: ``` @method_decorator(login_required, name='dispatch') class ProtectedView(TemplateView): template_name = 'secret.html' ``` If you have a set of common decorators used in several places, you can define a list or tuple of decorators and use this instead of invoking `method_decorator()` multiple times. These two classes are equivalent: ``` decorators = [never_cache, login_required] @method_decorator(decorators, name='dispatch') class ProtectedView(TemplateView): template_name = 'secret.html' @method_decorator(never_cache, name='dispatch') @method_decorator(login_required, name='dispatch') class ProtectedView(TemplateView): template_name = 'secret.html' ``` The decorators will process a request in the order they are passed to the decorator. In the example, `never_cache()` will process the request before `login_required()`. In this example, every instance of `ProtectedView` will have login protection. ## Mixins A special kind of **multiple inheritance** in Python where behaviors and attributes of multiple parent classes can be combined. 2 main situations where mixins are used: * You want to **provide a lot of optional features** for a class. * You want to **use one particular feature in a lot of different classes**. Further reading: [What is a Mixin and why are they useful?](https://stackoverflow.com/questions/533631/what-is-a-mixin-and-why-are-they-useful) Mixins are an **excellent way of reusing code across multiple classes**, but they come with some cost. The more your code is scattered among mixins, the harder it will be to read a child class. **You can only inherit from one generic view** - that is, only one parent class may inherit from [`View`](https://docs.djangoproject.com/en/2.1/ref/class-based-views/base/#django.views.generic.base.View) and the rest (if any) should be mixins. ## Querysets ## Forms All form classes are created as subclasses of either [`django.forms.Form`](https://docs.djangoproject.com/en/2.1/ref/forms/api/#django.forms.Form) or [`django.forms.ModelForm`](https://docs.djangoproject.com/en/2.1/topics/forms/modelforms/#django.forms.ModelForm). You can think of `ModelForm` as a subclass of `Form`. ### Bound and unbound form instances The distinction between [Bound and unbound forms](https://docs.djangoproject.com/en/2.1/ref/forms/api/#ref-forms-api-bound-unbound) is important: * **Unbound form:** has no data associated with it. When rendered to the user, it will be empty or will contain default values. * **Bound form:** has submitted data, and hence can be used to tell if that data is valid. If an invalid bound form is rendered, it can include inline error messages telling the user what data to correct. The form’s [`is_bound`](https://docs.djangoproject.com/en/2.1/ref/forms/api/#django.forms.Form.is_bound) attribute will tell you whether a form has data bound to it or not. ### GET and POST `GET` and `POST` are the only HTTP methods to use when dealing with forms. `GET` and `POST` are typically used for different purposes. #### GET Bundles the **submitted data into a string**, and uses this to **compose a URL**. Should be used only for requests that do not affect the state of the system. Suitable for things like a web search form, because the URLs that represent a `GET` request **can easily be bookmarked, shared, or resubmitted**. Unsuitable for a password form, because the password would appear in the URL, and thus, also in browser history and server logs, all in plain text. **Unsuitable for large quantities of data**, or for binary data, such as an image. A Web application that uses `GET` requests for admin forms is a security risk: it can be easy for an attacker to mimic a form’s request to gain access to sensitive parts of the system. `POST`, coupled with other protections like Django’s [CSRF protection](https://docs.djangoproject.com/en/2.1/ref/csrf/) offers more control over access. #### POST The browser bundles up the form data, encodes it for transmission, sends it to the server, and then receives back its response. ## Templates **Generate HTML dynamically** Contains the static parts of the desired HTML output as well as some special syntax describing how dynamic content will be inserted. A Django project can be configured with one or several **template engines** (or even zero if you don’t use templates). Django ships built-in backends for its own template system, creatively called the **Django template language (DTL)**, and for the popular alternative [Jinja2](http://jinja.pocoo.org/). Backends for other template languages may be available from third-parties. ### Components #### Engine Encapsulates an instance of the Django template system. The main reason for instantiating an [`Engine`](https://docs.djangoproject.com/en/2.1/ref/templates/api/#django.template.Engine) directly is to use the Django template language outside of a Django project. #### Template A compiled template #### Context holds some metadata in addition to the context data. It is passed to [`Template.render()`](https://docs.djangoproject.com/en/2.1/ref/templates/api/#django.template.Template.render) for rendering a template. #### Loaders Responsible for locating templates, loading them, and returning [`Template`](https://docs.djangoproject.com/en/2.1/ref/templates/api/#django.template.Template) objects. #### Context processors Functions that receive the current [`HttpRequest`](https://docs.djangoproject.com/en/2.1/ref/request-response/#django.http.HttpRequest) as an argument and return a [`dict`](https://docs.python.org/3/library/stdtypes.html#dict) of data to be added to the rendering context. Add common data shared by all templates to the context without repeating code in every view. Implementing a custom context processor is as simple as defining a function.