Django Une suite de 3 pour les débutants pour créer des applications simples. La dernière fois, j'ai créé C de CRUD, c'est-à-dire Créer une pièce avec une vue basée sur les classes. Cette fois, j'aimerais réécrire de la vue basée sur les classes en vue fonction et suivre le fonctionnement de Django tout en comparant les deux.
Ubuntu 20.04 LTS Python 3.8.2 Django 3.02
Le nom du projet est config et le nom de l'application est myapp. En d'autres termes, les deux commandes suivantes ont été exécutées
(myenv)$ django-admin startproject config .
(myenv)$ python manage.py startapp myapp
Le répertoire des modèles est créé dans la même hiérarchie que manage.py et setting.py a également été modifié. (Voir «Les débutants créent des applications faciles 1»)
index_view
class IndexView(generic.ListView):
template_name = 'myapp/index.html'
context_object_name = 'movie_list'
queryset = Movie.objects.all()
#Ce qui suit est la fonction-view
def index(request):
movie_list = Movie.objects.all()
return render(request, 'myapp/index.html', {'movie_list': movie_list})
En fait, il s'est terminé en 2 lignes ... La vue des fonctions a un code plus court. Que fais tu
Lorsqu'une page est demandée, Django crée un objet HttpRequest qui contient des métadonnées sur la requête. Django transmet ensuite HttpRequest comme première fonction de la fonction de vue pour charger la vue appropriée. Chaque vue doit renvoyer un objet HttpResponse.
Quelle est la demande d'argument? Qui demande quoi? Je me demandais, mais l'identité de ** request était un objet (instance) ** de HttpRequest.
Combines a given template with a given context dictionary and returns an HttpResponse object with that rendered text.
La fonction de rendu formate les données de type dictionnaire dans un fichier HTML et l'affiche. ** La dernière chose qui sort avec render () est l'objet HttpResponse (instance). ** **
Each non-abstract Model class must have a Manager instance added to it. Django ensures that in your model class you have at least a default Manager specified. If you don’t add your own Manager, Django will add an attribute objects containing default Manager instance.
** Il y a une chose appelée Manager pour extraire les données dans le modèle (base de données), et son nom est des objets. ** Donc Movie.objects.all () signifie "objets Movie (Manager), apportez toutes les données!".
detail_view
class MovieDetailView(generic.DetailView):
model = Movie
template_name = 'myapp/detail.html'
#Fonction à partir d'ici-view
def moviedetail(request, pk):
m = Movie.objects.get(pk=pk)
return render(request, 'myapp/detail.html', {'movie': m})
Seules deux lignes étaient nécessaires ici. Le pk dans la partie (request, pk) est le <int: pk> ʻdu chemin('movie / <int: pk> /',décrit dans urls.py. Ceci est changé. Oui. Si vous changez l'URL en «<int: movie_id>», changez-la en «(request, movie_id)». Ce que vous faites avec cette fonction est
register_director_view
class RegisterDirectorView(generic.CreateView):
model = Director
form_class = DirectorForm
template_name = 'myapp/register.html'
def get_success_url(self):
return reverse('myapp:registermovie')
#Fonction à partir d'ici-view
def registerdirector(request):
if request.method == "POST":
form = DirectorForm(request.POST)
if form.is_valid():
d = form.save(commit=False)
d.save()
return redirect('myapp:registermovie')
else:
form = DirectorForm()
return render(request, 'myapp/register.html', {'form': form})
La grande différence entre la vue basée sur la classe et la vue fonction est ici chez CreateView. La vue des fonctions est plus facile à comprendre pour comprendre le mécanisme.
Le navigateur communique avec le serveur via HTTP, mais la méthode est POST. En fait, il y a une description dans register.html comme <form method =" POST ">, ce qui signifie que lorsque le bouton de sauvegarde est pressé, les données seront envoyées comme POST, qui est entrelacé avec cette ligne.
request.POST est un objet de type dictionnaire. Vous pouvez spécifier la clé pour accéder aux données que vous avez envoyées. Dans ce cas, request.POST ['choice'] renvoie l'ID du choix sélectionné sous forme de chaîne. La valeur de request.POST est toujours une chaîne.
En d'autres termes, les données saisies dans "request.POST" sont incluses. Cela signifie qu'un objet appelé form est créé en l'appliquant à DirectorForm.
The primary task of a Form object is to validate data. With a bound Form instance, call the is_valid() method to run validation and return a boolean designating whether the data was valid:
Si un objet appelé formulaire est valide. S'il y a une omission d'entrée, il jouera avec cela. Je ne connaissais pas les termes validation (vérifier si les données saisies étaient correctes) et nettoyage des données (formatage des données dans un formulaire facile à utiliser), donc au début, j'étais malade.
This save() method accepts an optional commit keyword argument, which accepts either True or False. If you call save() with commit=False, then it will return an object that hasn’t yet been saved to the database. In this case, it’s up to you to call save() on the resulting model instance. This is useful if you want to do custom processing on the object before saving it, or if you want to use one of the specialized model saving options. commit is True by default.
Le formulaire contenant les données est enregistré dans un objet appelé d, mais il n'est pas encore dans la base de données. Je me suis demandé pourquoi je faisais cela, mais il semble que je pourrais ajouter des données à ce formulaire plus tard et les enregistrer à nouveau dans la base de données. Est-ce quelque chose comme un stockage temporaire? Ensuite, quand il est finalement enregistré dans la base de données avec d.save () sur la ligne suivante.
redirect () dit "Fly to the address in ()", et en dessous d'autre dit "Create an empty form and render it in register.html". Si vous utilisez les connaissances acquises de cette manière, vous pourrez lire de plus en plus de code. Je suis content d'avoir évolué.
register_movie_view
class RegisterMovieView(generic.CreateView):
model = Movie
form_class = MovieForm
template_name = 'myapp/register.html'
def get_success_url(self):
return reverse('myapp:movie_detail', kwargs={'pk': self.object.pk })
#Fonction à partir d'ici-view
def registermovie(request):
if request.method == "POST":
form = MovieForm(request.POST)
if form.is_valid():
m = form.save(commit=False)
m.save()
return redirect('myapp:movie_detail', pk=m.pk)
else:
form = MovieForm()
return render(request, 'myapp/register.html', {'form': form})
Le code est presque le même que la dernière fois. Si vous osez le dire, c'est la partie redirect ('myapp: movie_detail', pk = m.pk), mais cela signifie-t-il "voler le pk de l'objet m comme le pk de movie_detail"?
writing_log_view
class WritingLogView(generic.CreateView):
model = Log
form_class = LogForm
template_name = 'myapp/register.html'
def get_success_url(self):
return reverse('myapp:movie_detail', kwargs={'pk': self.object.movie.pk })
#Fonction à partir d'ici-view
def writinglog(request):
if request.method == "POST":
form = LogForm(request.POST)
if form.is_valid():
l = form.save(commit=False)
l.save()
return redirect('myapp:movie_detail', pk=l.movie.pk)
else:
form = LogForm()
return render(request, 'myapp/register.html', {'form': form})
Le code est presque le même. "Je peux lire! Je peux lire!" (Par Muska)
La vue basée sur les classes sera plus facile à écrire à la fin, mais la vue des fonctions est plus facile à comprendre le mécanisme et on a l'impression que vous pouvez atteindre les détails. Est-ce comme une voiture automatique et une voiture manuelle? Non, si vous le réécrivez dans Function-view, cela ne fonctionnera que si vous réécrivez correctement urls.py, donc ce n'est pas mal. La prochaine fois, nous prévoyons de mettre en œuvre CRUD UD, c'est-à-dire mettre à jour et supprimer. C'est probablement plus facile à comprendre si vous écrivez le code côte à côte comme cette fois. Si vous avez des erreurs, veuillez les signaler et nous donner des conseils. Le but est-il proche ...?
Recommended Posts