Django2 View configuration pattern

Premise

Beginners. It is an explanation that such an understanding may be good in practice.

environment

First, check the initial configuration of View

In Django, first create a template for your project and app with the following command:

python


> django-admin startproject some_project
> cd some_project
> python manage.py startapp some_app

Then, the structure of the folder is as follows.

python


> tree /f some_project
C:\***\SOME_PROJECT
│  manage.py
│
├─some_app
│  │  admin.py
│  │  apps.py
│  │  models.py
│  │  tests.py
│  │  views.py # <=Early View(View)Is a 1-file structure
│  │  __init__.py
│  │
│  └─migrations
│          __init__.py
│
└─some_project
    │  settings.py
    │  urls.py
    │  wsgi.py
    │  __init__.py
    │
    └─__pycache__
            settings.cpython-37.pyc
            __init__.cpython-37.pyc

As mentioned above, the View at the time of creating the application consists of one file called views.py.

If you just want to give it a try, it's okay as it is, In the actual project, even if it takes a little time to start It is better to give priority to ease of maintenance.

View configuration pattern

The structure of View can be changed by using the Python mechanism. I will briefly explain from what perspective you can think of the configuration, including recommendations.

Function-based / class-based

Class-based is recommended because you may want to use the default class in your project.

As a file / package

It is troublesome for multiple people to handle one file, so it is recommended to package it.

Import / not import in \ _ \ _ init \ _ \ _.py

When packaging, it is recommended to import with \ _ \ _ init \ _ \ _. Py. Only urls.py imports views, so It's not a mast, but from the caller's point of view

python


from some_app.views.category.sub_category. import SomeView

than

python


from some_app.views import SomeView

Is gentler because it doesn't make you aware of the configuration under the package.

1 file 1 class / multiple classes

I don't think either one is better, I think it's good to decide the rules.

For example

--CRUD function is defined in one class per file --The CRUD function that handles common data is defined in one file. --Define functions for Ajax that handle common data in one file

And so on. When deciding the rules, it is good to consider the following things.

-Is it easy to imagine and search the related source code when you look at the screen? -Isn't it troublesome when editing with an editor? --Isn't it frequent for multiple people to edit the same file?

Use / do not use generic view

It may be a bit extreme, but we recommend the following:

** List screen ** ListView (django.views.generic.ListView) ** Other ** View (django.views.View)

ListView is recommended because it can use the pagination function. We do not recommend using other generic views.

There are many things to start with, but the simple reason is as follows. ・ It takes time to read the source code => ・ The benefits are not worth it => It becomes complicated ・ It becomes difficult to debug

Also, Django has Model (QuerySet) / Form. There are some useful features that require learning costs.

Rather than understanding generic views It is definitely advisable to spend learning costs on them.

As an example, CreateView (django.views.generic) has the following inheritance relationship:

that's all.

Recommended Posts

Django2 View configuration pattern
Django function-based view
Django class-based view
Django
Django tutorial summary for beginners by beginners ③ (View)
Ajax in Django (using generic class view)