ხედი არის Django-ის ლოგიკის ფენა — ფუნქცია ან კლასი, რომელიც იღებს HTTP მოთხოვნას, ასრულებს ლოგიკას (მოდელების მოთხოვნა, შეყვანის დამუშავება) და აბრუნებს HTTP პასუხს. ხედები ის ადგილია, სადაც თქვენ მართავთ რას ხდება URL-ის წვდომისას.
ფუნქციაზე დაფუძნებული ხედები (FBVs)
from django.shortcuts import render, get_object_or_404
from django.http import JsonResponse, HttpResponse
def article_list(request):
articles = Article.objects.all() # query models
return render(request, "articles.html", {"articles": articles}) # render a template
def article_detail(request, pk):
article = get_object_or_404(Article, pk=pk) # 404 if not found
return render(request, "detail.html", {"article": article})
def api_articles(request):
data = list(Article.objects.values("title", "body"))
return JsonResponse(data, safe=False) # return JSON instead of HTML
ფუნქციაზე დაფუძნებული ხედი იღებს request-ს (პლუს ნებისმიერი URL პარამეტრი), აკეთებს თავის საქმეს და აბრუნებს პასუხს — render() HTML-ისთვის, JsonResponse JSON-ისთვის, HttpResponse ნედლი გამოსატანად.
სხვადსხვა HTTP მეთოდებისა და შეყვანის დამუშავება
def create_article(request):
if request.method == "POST":
form = ArticleForm(request.POST)
if form.is_valid():
form.save()
return redirect("article_list") # redirect after a successful POST
else:
form = ArticleForm()
return render(request, "create.html", {"form": form})
ხედები შემოწმებენ request.method-ს (GET, POST და ა.შ.) და ელდებიან შეყვანის წვდომას request.POST, request.GET, request.user და ა.შ. საშუალებით.
კლასზე დაფუძნებული ხედები (CBVs) — გამოყენებადი, ნაკლები ბოილერფიანი კოდი
from django.views.generic import ListView, DetailView
# generic CBVs handle common patterns with minimal code
class ArticleListView(ListView):
model = Article # automatically lists all articles
template_name = "articles.html"
class ArticleDetailView(DetailView):
model = Article
Django ასევე გთავაზობთ კლასზე დაფუძნებულ ხედებს — კერძოდ, ზოგად ხედებს (ListView, DetailView, CreateView), რომლებიც აგებენ ხშირად გამოყენებულ ნიმუშებს (სიის ჩვენება, დეტალი, CRUD) ძალიან მცირე კოდით, რაც აკლებს ბოილერფიანი კოდი.
ხედის როლი მოთხოვნის ნაკადში
Request → URL routing → VIEW (logic) → queries models, renders template → Response
The view is the orchestrator: it connects the URL, the data (models), and the
presentation (template) to produce a response.
რატომ მნიშვნელოვანია ეს
ხედები არის Django-ის ლოგიკის ფენა (MVT-ის "V", MVC-ის კონტროლერის ეკვივალენტი) — იმ ადგილი, სადაც თქვენ ხვდებით ყველა მოთხოვნას, რაც მათ საფუძველს ხდის Django აპლიკაციის აგებას.
ხედების გაგება აუცილებელია, რადგან ისინი არიან ორქესტრატორი, რომელიც ყველაფერს ერთმანეთში აკავშირებს: მოთხოვნის მიღება, ბიზნეს-ლოგიკის გამოყენება, მოდელების მოთხოვნა მონაცემებისთვის, მომხმარებლის შეყვანის დამუშავება (ფორმები) და სათანადო პასუხის დაბრუნება (HTML შაბლონების მეშვეობით, ან JSON API-სთვის).
ფუნქციაზე დაფუძნებული ხედების დაწერა (აშკარა, მოქნილი — კარგი მორგებული ლოგიკისთვის), სხვადსხვა HTTP მეთოდის დამუშავება და მოთხოვნის მონაცემების წვდომა, და კლასზე დაფუძნებული/ზოგადი ხედების გამოყენება (რომელიც მოიჩრდილებს ბოილერფიანი კოდის მოხმარებას ხშირი ნიმუშებისთვის, როგორიცაა სიის ჩვენება და CRUD) მოიცავს Django კიდეების აგების პრაქტიკული სპექტრს.
ხედები არიან იმ ადგილი, სადაც აპლიკაციის მოთხოვნის დამუშავების ლოგიკის უმეტესი ნაწილი ცხოვრობს, ამიტომ მათი დაუფლება — მოთხოვნა/პასუხის ციკლი, არჩევანი ფუნქციაზე დაფუძნებული და კლასზე დაფუძნებული მიდგომებს შორის, და ის თუ როგორ აკავშირებენ ხედები URLs-ს მოდელებითა და შაბლონებით — არის ძირითადი, ყოველდღიური ცოდნა ნებისმიერი Django დეველოპერისთვის და ფრაიმვორკის მიერ მოთხოვნების დამუშავების ცენტრალური ნაწილი.
