Modèle de configuration de Django2 View

supposition

Débutants. C'est une explication qu'une telle compréhension peut être bonne dans la pratique.

environnement

Tout d'abord, vérifiez la configuration initiale de View

Dans Django, créez d'abord un modèle pour votre projet et votre application avec la commande suivante:

python


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

Ensuite, la structure du dossier est la suivante.

python


> tree /f some_project
C:\***\SOME_PROJECT
│  manage.py
│
├─some_app
│  │  admin.py
│  │  apps.py
│  │  models.py
│  │  tests.py
│  │  views.py # <=Vue anticipée(Vue)Est une structure de fichier
│  │  __init__.py
│  │
│  └─migrations
│          __init__.py
│
└─some_project
    │  settings.py
    │  urls.py
    │  wsgi.py
    │  __init__.py
    │
    └─__pycache__
            settings.cpython-37.pyc
            __init__.cpython-37.pyc

Comme mentionné ci-dessus, la vue lors de la création d'une application se compose d'un fichier appelé views.py.

Si tu fais juste un essai, ça va comme ça, Dans le projet proprement dit, même si le démarrage prend un peu de temps Il vaut mieux donner la priorité à la facilité d'entretien.

Afficher le modèle de configuration

La structure de View peut être modifiée en utilisant le mécanisme de Python. Je vais expliquer brièvement sous quel point vous pouvez penser de la configuration, y compris les recommandations.

Basé sur la fonction / basé sur la classe

Basée sur les classes est recommandée car vous souhaiterez peut-être utiliser la classe par défaut dans votre projet.

En tant que fichier / package

Il est difficile pour plusieurs personnes de gérer un fichier, il est donc recommandé de le conditionner.

Importer / ne pas importer avec \ _ \ _ init \ _ \ _.py

Lors du packaging, il est recommandé d'importer avec \ _ \ _ init \ _ \ _. Py. Seule urls.py importe les vues, donc Ce n'est pas un must, mais du point de vue de l'appelant

python


from some_app.views.category.sub_category. import SomeView

que

python


from some_app.views import SomeView

Est plus doux car il ne vous informe pas de la composition sous l'emballage.

1 fichier 1 classe / plusieurs classes

Je ne pense pas que l'un ou l'autre soit meilleur Je pense qu'il est bon de décider des règles.

Par exemple

Etc. Au moment de décider des règles, il est bon de prendre en compte les éléments suivants.

-Est-il facile d'imaginer et de rechercher le code source associé lorsque vous regardez l'écran? -N'est-ce pas gênant lors de l'édition avec un éditeur?

Utiliser / ne pas utiliser la vue générique

Cela peut être un peu extrême, mais nous recommandons ce qui suit:

** Écran de liste ** ListView (django.views.generic.ListView) ** Autre ** View (django.views.View)

ListView est recommandé car il peut utiliser la fonction de nation de page. Nous vous déconseillons d'utiliser d'autres vues génériques.

Il y a beaucoup de choses pour commencer, mais la simple raison est la suivante. ・ La lecture du code source prend du temps => ・ Les avantages n'en valent pas la peine => Ça devient compliqué ・ Ça devient difficile à déboguer

De plus, Django a Model (QuerySet) / Form. Certaines fonctionnalités utiles nécessitent des coûts d'apprentissage.

Plutôt que de comprendre la vue générique Il est certainement conseillé de leur consacrer des frais d'apprentissage.

Par exemple, CreateView (django.views.generic) a la relation d'héritage suivante.

c'est tout.

Recommended Posts

Modèle de configuration de Django2 View
Vue basée sur les fonctions Django
Vue basée sur les classes Django
Django
Résumé du tutoriel Django pour les débutants par les débutants ③ (Afficher)
Ajax dans Django (en utilisant la vue de classe générique)