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: It is the heart of the system. It handles request and responses, setting up database connections and loading add-ons and specifies Django framework and URL parsing.
To set up a database in Django, you can use the command edit my site/ setting.py, it is a normal python module with module level representing Django settings.
Django uses SQLite database by default. It is easy for Django users because it doesn’t require any other type of installation. In the case of other databases, you have the following keys in the DATABASE ‘default’ item to match your database connection settings.
Engines: you can change database by using ‘django.db.backends.sqlite3’ , ‘django.db.backeneds.mysql’, ‘django.db.backends.postgresql_psycopg2’, ‘django.db.backends.oracle’
Name: The name of your database. In the case if you are using SQLite as your database, in that case, a database will be a file on your computer, Name should be a full absolute path, including the file name of that file.
You can add setting likes setting like Password, Host, User, etc. in your database, if you are not choosing SQLite as your database.
The session framework facilitates you to store and retrieve arbitrary data on a per-site visitor basis. It stores data on the server side and abstracts the receiving and sending of cookies. A session can be implemented through a piece of middleware.
Django is a web framework in python to develop a web application in python. Django is a free and open source web application framework, written in Python. Django makes easier to build better web applications quickly and with less code.
We often find that Django developers exclusively those new to the framework and even some advanced users choose to use function based views for most projects. This can be attributed firstly to the simplicity of using FBVs and a lack of understanding of the great advantages of using Class Based Views.
In this article we will be highlighting some of the major advantages and the features of CBV.
SOME OF THE PROS OF USING CLASS BASED VIEW:
Code reusability – In CBV, a view class can be inherited by another view class and altered for a different use case.
Code extendibility – CBV can be extended to include more functionalities using Mixins.
Code structuring – In CBVs a class based view helps the developer to respond different http request with different class instance methods instead of conditional branching statements inside a single function based view.
Django class based view provides a class instance method as_view() which serves as an entry point for any generic CBV. Django URL resolver expects to send the request passed through it to a function. The as_view() class instance method in each generic view creates a hook for calling the class just like a method.
As such, the url configuration for calling a CBV follows the pattern below:
urlpatterns = [
url(r’^homepage/’, ClassView.as_view(), name = “url_name”)
]
The as_view() method then calls the dispatch() method which in turn calls the class instance method defined for the applicable http request method if available or throws an HttpResponseNotAllowed exception.
CBV.as_view() ——> CBV.dispatch() ——————–
| | | | and so on.
v v v v
get post head put
Base class attributes can be overridden in child class as with the standard Python approach. Instead, the new attribute can be passed as an argument to the as_view() method of the CBV.
USING MIXINS:
One of the benefits of using a Class based view its extendibility, this quality is further improved through the use of Mixins.
Mixins are a form of multiple inheritances that lets the combination of behavior from multiple parent classes. They are used to add additional functionality and behavior to classes. Mixins are intended to be inherited and not implemented directly. In CBVs Mixins are passed as leftmost argument while Django generic view classes are placed to the right.
Extending a class view with multiple Mixins can lead to some unforeseen behavior. However, if used with caution, mixins are great tools for adding robust functionalities to a CBV.
For instance:
class NewMixin(object):
def do_whatever(self, *args, **kwargs):
The above mixin is used as below:
from django.views.generic import TemplateView
class FreshViewClass(NewMixin, TemplateView):
def do_something_awesome(self):
continue here
The methods defined in the mixin can be called directly in the FreshViewClass class.