Использование метода get_object_or_404()
На данный момент, если пользователь вручную запрашивает несуществующую тему или запись, он получает ошибку сервера 500. Django пытается отобразить страницу, но не располагает достаточной информацией для этого, что приводит к ошибке 500. Такая ситуация более точно обрабатывается как ошибка 404, и это поведение можно реализовать при помощи вспомогательной функции Django get_object_or_404(). Эта функция пытается получить запрошенный объект из базы данных, а если этот объект не существует — инициирует исключение 404. Мы импортируем эту функцию в views.py и используем ее вместо get():
from django.shortcuts import render, get_object_or_404
from django.http import HttpResponseRedirect, Http404
def topic(request, topic_id):
«»»Выводит одну тему и все ее записи.»»»
# Проверка того, что тема принадлежит текущему пользователю.
Use get_object_or_404 in Django to write lesser code
For the sake of an example, let us consider a model called Record that is defined as follows:
If you had to write an API to fetch a particular Record object using the id field. It would look something like this:
These 4 lines of code can be converted into a single line of code using get_object_or_404:
TL;DR
To retrieve objects from a database, use get_object_or_404 as opposed to getting the object using the ORM way and throwing an exception if it does not exist. This method pretty much does the same thing under the hood.
�� �� Enjoyed reading?
I write about navigating my life around being a technical co-founder of a startup, leveraging Django to build SaaS products and leading a wholesome life.
Subscribe to my weekly newsletter to get notified on new content published every Sunday. I promise to deliver value and not BS ��
Click here if you don’t see the subscribe form.
Ваше первое Django-приложение, часть 3
Начнём с того места, где мы остановились во 2 части. Мы продолжаем написание приложения Web-опроса и сосредоточимся теперь на создании интерфейса пользователя — «views».
Философия
view — это «тип» Web-страницы в вашем приложении Django, который как правило выполняет определенную функцию и имеет конкретный шаблон. Например, в weblog-приложении, у вас могут быть следующие views:
- домашняя страница блога — отображает последние несколько посещений блога.
- Страница «детализации» посещений — ссылка на страницу с информацией об одном посещении.
- страница архива за год — отображает помесячно все посещения за текущий год.
- страница архива за месяц — отображает посещения по дням за текущий месяц.
- страница архива за день — отображает все посещения за текущий день.
- Комментарии — комментарии, публикуемые вручную за текущее посещение.
В нашем приложении Опроса, будет четыре views:
- страница «архива» — отображает последние несколько опросов.
- страница «детализации» — отображает вопрос с формой для голосования.
- страница «результатов» — отображает результаты определённого опроса.
- голосование — голосование за определенный вариант конкретного опроса.
В Django, каждый view представлен простой функцией Python.
Дизайн ваших URLs
Первый шаг к написанию views, это дизайн структуры вашего URL. Это можно сделать, создав Python-модуль, называющийся URLconf. URLconfs — это то, как Django связывает данный URL с данным Python-кодом.
Когда пользователь запрашивает страницу Django, система просматривает параметр ROOT_URLCONF который содержит строку точечного синтаксиса Python. Django загружает этот модуль и ищет переменную urlpatterns , которая является последовательностью кортежей в следующем формате:
(regular expression, Python callback function [, optional dictionary])
Django начинает с первого регулярного выражения и далее вниз по списку, сравнивая требуемый URL с каждым регулярным выражением, пока не найдёт подходящий.
После этого, Django вызывает callback-функцию Python, с первым аргументом в качестве HttpRequest -объекта, любые «зафиксированные» значения из регулярного выражения в качестве ключевых аргументов, и, дополнительно, произвольные ключевые аргументы из словаря (дополнительный третий элемент в кортеже).
Дополнительную информацию о HttpRequest -объектах, смотри здесь: Request and response objects. Более детальную информацию о URLconfs, смотри здесь: URL dispatcher.
Команда django-admin.py startproject mysite , aвыполненная в начале 1 части руководства, создала по умолчанию URLconf в mysite/urls.py . Это также автоматически настроило ROOT_URLCONF (в settings.py ) чтобы указать на этот файл:
ROOT_URLCONF = 'mysite.urls'
Пора привести пример. Измените mysite/urls.py так, чтобы он выглядел следующим образом:
from django.conf.urls.defaults import * from django.contrib import admin admin.autodiscover() urlpatterns = patterns('', (r'^polls/$', 'mysite.polls.views.index'), (r'^polls/(?P\d+)/$', 'mysite.polls.views.detail'), (r'^polls/(?P\d+)/results/$', 'mysite.polls.views.results'), (r'^polls/(?P\d+)/vote/$', 'mysite.polls.views.vote'), (r'^admin/', include(admin.site.urls)), )
Это стоит посмотреть! Если кто — то запрашивает страницу с вашего сайта — скажем, «/polls/23 / «, то Django загрузит этот Python-модуль, потому что так прописано в настройках ROOT_URLCONF . Он находит переменную urlpatterns и просматривает по очереди все регулярные выражения. Когда он находит подходящее регулярное выражение — r'^polls/(?P\d+)/$' — то он загружает функцию detail() из mysite/polls/views.py . И наконец, он вызывает эту функцию detail() вот таким образом:
detail(request=, poll_id='23')
poll_id получает значение '23' после обработки регулярного выражения (?P\d+) . Использование круглых скобок вокруг шаблона «фиксирует» текст, соответствующий этому шаблону и отправляет его функции view в качестве аргумента; ?P определяет имя, которое будет использоваться, для определения соответствующего шаблона; а \d+ iявляется регулярным выражением для сопоставления последовательности цифр (т. е. число).
Поскольку URL-шаблоны являются регулярными выражениями, то действительно нет никаких ограничений в том, что Вы можете сделать с ними. И нет необходимости добавлять URL cruft, например .php - но если у вас есть хорошее чувство юмора, то в этом случае Вы можете сделать что-то вроде этого:
(r'^polls/latest\.php$', 'mysite.polls.views.index'),
Не делайте так. Это глупость.
Обратите внимание, что эти регулярные выражения не ищут параметры GET и POST, или имя домена. Например, в запросе к http://www.example.com/myapp/ , URLconf будет искать myapp/ . В запросе к http://www.example.com/myapp/?page=3 , URLconf будет искать myapp/ .
Если вам нужна помощь по использованию регулярных выражений, то смотри здесь: Wikipedia's entry и здесь: Python documentation. Также, на мой взгляд, книга O'Reilly "Mastering Regular Expressions" Джеффри Фридлома является прекрасным помощником по данной теме.
Примечание: эти регулярные выражения компилируются, когда загружается в первый раз модуль URLconf. Они супер быстрые.
Пишем своё первое view
Ок, мы ещё не создали ни одного views - у нас есть только URLconf. Но давайте убедимся, что Django правильно следует за URLconf.
Запустите сервер Web-разработки Django:
python manage.py runserver
Теперь перейдите на "http://localhost:8000/polls/" на свой домен в вашем Web-браузере. Вы должны увидеть страницу с сообщением об ошибке:
ViewDoesNotExist at /polls/ Tried index in module mysite.polls.views. Error was: 'module' object has no attribute 'index'
Эта ошибка произошла из-за того, что Вы не прописали функцию index() в модуле mysite/polls/views.py .
Попробуйте "/polls/23 / ", "/polls/23/results / " и "/polls/23/vote / ". Из сообщения об ошибке Вы узнаете, какой view ищет Django (и не может найти, потому что Вы не написали еще никаких view).
Пора создать свой первый view. Откройте файл mysite/polls/views.py и запишите в него следующий Python-код:
from django.http import HttpResponse def index(request): return HttpResponse("Hello, world. You're at the poll index.")
Это самый простой view. Зайдите в " / polls / " через свой браузер, чтобы увидеть текст.
Теперь давайте добавим ещё несколько view. Они будут немного отличаться, потому что они принимают аргумент:
def detail(request, poll_id): return HttpResponse("You're looking at poll %s." % poll_id) def results(request, poll_id): return HttpResponse("You're looking at the results of poll %s." % poll_id) def vote(request, poll_id): return HttpResponse("You're voting on poll %s." % poll_id)
Зайдите в своём браузере в "/polls/34 / ". Он запустит метод деталь () и отобразит любой ID, который Вы предоставите в URL. Попробуйте также "/polls/34/results / " и "/polls/34/vote / " - они отобразят результаты указателя места заполнения и страниц голосования.
Пишем views, которые на самом деле могут что-то делать
Каждое view отвечает за выполнение одного из двух: Возвращает HttpResponse -объект, содержащий контент для требуемой страницы, или выбрасывая исключение, такое, как Http404 . Остальное зависит от вас.
Ваш view может читать записи из базы данных, или нет. Он может использовать систему шаблонов Django - или стороннюю систему шаблонов Python - или нет. Он может генерировать PDF-файл, выводить XML, создавать ZIP-файл на лету, или что-то иное, что Вы захотите, используя те библиотеки Python, которые Вы захотите.
Все что хочет Django, это HttpResponse . Или исключение.
Так как это удобно, давайте использовать собственные API-базы данных Django, о которых шла речь в 1 части. Вот пример index() view, который отображает последние 5 вопросов вопросника в системе, отделенные запятыми, согласно даты публикации:
from mysite.polls.models import Poll from django.http import HttpResponse def index(request): latest_poll_list = Poll.objects.all().order_by('-pub_date')[:5] output = ', '.join([p.question for p in latest_poll_list]) return HttpResponse(output)
Но здесь существует одна проблема: дизайн страницы жестко закодирован в view. Если Вы хотите изменить способ представления страницы, вам придется изменить код Python. Так что, давайте с помощью системы шаблонов Django, отделим дизайн от Python:
from django.template import Context, loader from mysite.polls.models import Poll from django.http import HttpResponse def index(request): latest_poll_list = Poll.objects.all().order_by('-pub_date')[:5] t = loader.get_template('polls/index.html') c = Context( 'latest_poll_list': latest_poll_list, >) return HttpResponse(t.render(c))
Данный код загружает шаблон "polls/index.html" и передает ему контекст. Контекст - это словарь, отображающий имена переменной шаблона в Python-объекты.
Перезагрузите страницу. Вы увидите следующую ошибку:
TemplateDoesNotExist at /polls/ polls/index.html
А шаблона всё ещё нет. Сначала, создайте каталог в любом месте вашей файловой системы, к контенту которого может обратиться Django (Django запускается, как только пользователь заходит на ваш сервер). Но не создавайте его в корне. Вам также не следует его делать общедоступным, по причине безопасности. Затем измените TEMPLATE_DIRS в settings.py чтобы сообщить Django где искать шаблоны - также, как Вы это делали в разделе "Настройка внешнего вида интерфейса администратора" во второй части руководства.
Когда Вы это сделали, создайте каталог polls iв директории шаблона. Создайте в нём файл index.html . Обратите внимание, что наш вышеприведённый код loader.get_template('polls/index.html') отображается в "template_directory]/polls/index.html" в файловой системе.
Поместите следующий код в этот шаблон:
if latest_poll_list %> for poll in latest_poll_list %> poll.question >> endfor %> else %> No polls are available. endif %>
Загрузите страницу в вашем Web-браузере, и Вы увидите маркированный список, содержащий опрос "What's up" из первой части руководства.
Ярлык: render_to_response()
Это обычное дело загрузить шаблон, заполнить контекст и вернуть HttpResponse -объект с результатом представленного шаблона. Django предоставляет ярлык. Вот полный index() view:
from django.shortcuts import render_to_response from mysite.polls.models import Poll def index(request): latest_poll_list = Poll.objects.all().order_by('-pub_date')[:5] return render_to_response('polls/index.html', 'latest_poll_list': latest_poll_list>)
Обратите внимание, что, как только мы сделали это во всех views, нам нет больше необходимости импортировать loader , Context и HttpResponse .
Функция render_to_response() принимает имя шаблона в качестве первого аргумента и словарь в качестве необязательного второго аргумента. Это возвращает HttpResponse -объект данного шаблона, предоставленного с данным контекстом.
Выброс исключения 404
Теперь, давайте займемся страницей, отображающей вопрос для данного опроса. Вот её view:
from django.http import Http404 # . def detail(request, poll_id): try: p = Poll.objects.get(pk=poll_id) except Poll.DoesNotExist: raise Http404 return render_to_response('polls/detail.html', 'poll': p>)
Вот новая концепция: view выбрасывает исключение Http404 если опрос с требуемым ID не существует.
Мы обсудим немного позже то, что Вам надо написать в шаблоне polls/detail.html но если Вам хочется побыстрее получить пример вышеупомянутой работы, то:
даст вам возможность начать прямо сейчас.
Ярлык: get_object_or_404()
Часто бывает при использовании get() выбрасывается Http404 если объект не существует. Django предоставляет ярлык. Вот detail() view:
from django.shortcuts import render_to_response, get_object_or_404 # . def detail(request, poll_id): p = get_object_or_404(Poll, pk=poll_id) return render_to_response('polls/detail.html', 'poll': p>)
Функция get_object_or_404() принимает модель Django в качестве первого аргумента и произвольное число ключевых аргументов, которые он передаёт функции модуля get() . Он выбрасывает Http404 если объект не существует.
Почему мы используем вспомогательную get_object_or_404() вместо того, чтобы автоматически захватывать исключения ObjectDoesNotExist на более высоком уровне, или иметь выброс исключения Http404 API модели вместо ObjectDoesNotExist ?
Потому что это соединило бы уровень модели с уровнем view. Одна из передовых дизайнерских идей Django состоит в том, чтобы поддержать слабую связь.
Есть ещё функция get_list_or_404() , которая работает так же, как get_object_or_404() -- за исключением использования filter() вместо get() . Но если список пуст, то выбрасывается Http404 .
Пишем view исключения 404 (страница, не найдена)
Если выбрасывается исключение Http404 изнутри вьюхи, то Django загружает специальный view для обработки исключения 404. Он находит его, совершая поиск переменной handler404 , которая является строкой, написанной в точечном синтаксисе Python - тот же самый формат, который использует обычный URLconf. Сам по себе view исключения 404 не имеет ничего особенного: Это просто обычный view.
Обычно вам не надо его писать. По умолчанию, URLconfs имеет следующую строку:
from django.conf.urls.defaults import *
Он занимается установкой handler404 в текущем модуле. Как Вы видите в django/conf/urls/defaults.py , handler404 установлен в django.views.defaults.page_not_found() по умолчанию.
Вот ещё дополнительные четыре пункта о views исключения 404:
- Если DEBUG настроена на значение True ((в настройках модуля), то 404 view никогда не будет использоваться (и таким образом, шаблон 404.html никогда не будет отображаться), потому что вместо него будет отображён traceback.
- Также 404 view вызывается, если Django не находит соответствия после проверки каждого регулярного выражения в URLconf.
- Если Вы не задаёте 404 view, а используете значение по умолчанию, которое рекомендуется, то у вас есть ещё одно обязательство: создать шаблон 404.html в корне директории шаблонов. По умолчанию 404 view будет использовать этот шаблон для всех 404 ошибок.
- Если DEBUG настроена на значение False (в настройках модуля) и если Вы не создали файл 404.html то вместо него будет выброшен Http500 . Поэтому не забудьте создать 404.html .
Пишем view ошибки 500 (ошибка сервера)
Точно так же URLconfs могут назначить handler500 , который указывает на view для вызова в случае ошибки сервера. Ошибки сервера случаются, когда у вас истекает время в view-коде.
Использование системы шаблонов
Вернемся к detail() view нашего приложения опроса. Вот как может выглядеть шаблон "polls/detail.html" :
poll.question >> for choice in poll.choice_set.all %> choice.choice >> endfor %>
Система шаблона использует синтаксис точечного поиска, чтобы получить доступ к атрибутам переменной. В примере > , сначала Django делает поиск по словарю у объекта poll . В случае неудачи, он совершает атрибутный поиск. Если данный поиск также закончится неудачей, то он пытается вызвать метод question() у объекта poll.
Вызов метода происходит в цикле : poll.choice_set.all интерпретируется как Python-код poll.choice_set.all() , который возвращает итератор выбора объектов и подходит для использования в тэге .
Для более подробной информации см. template guide.
Упрощение URLconfs
Найдите немного времени для работы с views и системой шаблонов. Как только Вы начнёте изменять URLconf, Вы заметите, что в нём есть немного лишнего:
urlpatterns = patterns('', (r'^polls/$', 'mysite.polls.views.index'), (r'^polls/(?P\d+)/$', 'mysite.polls.views.detail'), (r'^polls/(?P\d+)/results/$', 'mysite.polls.views.results'), (r'^polls/(?P\d+)/vote/$', 'mysite.polls.views.vote'), )
А именно, в каждом повторном вызове находится mysite.polls.views .
Поскольку это распространённый случай, фреймворк URLconf предоставляет ярлык для общих префиксов. Вы можете вынести за скобки общие префиксы и добавить их в качестве первого аргумента к patterns() , например, так:
urlpatterns = patterns('mysite.polls.views', (r'^polls/$', 'index'), (r'^polls/(?P\d+)/$', 'detail'), (r'^polls/(?P\d+)/results/$', 'results'), (r'^polls/(?P\d+)/vote/$', 'vote'), )
Это функционально похоже на предыдущее форматирование, только немного более чистое.
Декаплинг URLconfs
Раз мы этим занялись, давайте найдём немного времени на то, чтобы отделить URLs нашего приложения Опроса от конфигурации нашего Django-проекта. Приложения Django являются сменными (pluggable) - т. е. любое приложение должно открываться в другой инсталляции Django с минимальными усилиями.
Наше приложение опроса является почти "развязанным", с этой точки зрения, благодаря строгой структуре каталогов, которую создал Python python manage.py startapp но одна его часть является связанной с настройками Django:The URLconf.
Мы изменили URL в mysite/urls.py , но URL-дизайн приложения заточен под него, а не под инсталляцию Django - поэтому, давайте переместим URLs в каталог приложения.
Скопируйте файл mysite/urls.py в mysite/polls/urls.py . Затем, измените mysite/urls.py чтобы удалить специальные URLs для Опроса и вставить include() :
# . urlpatterns = patterns('', (r'^polls/', include('mysite.polls.urls')), # .
include() , просто ссылается на другой URLconf. Обратите внимание, что регулярное выражение не имеет $ (символ конца строки), а имеет косую черту вправо. Всякий раз, когда Django сталкивается с include() , он обрубает совпадающую часть URL и отправляет оставшуюся строку в URLconf для дальнейшей обработки.
Вот что происходит, если пользователь заходит в "/polls/34 / " в этой системе:
- Django находит совпадающий текст в '^polls/'
- Затем удаляет его ( "polls/" ) и отправляет оставшийся текст -- "34/" -- в 'mysite.polls.urls' URLconf для дальнейшей обработки.
Теперь, когда мы сделали декаплинг, мы должны сократить 'mysite.polls.urls' URLconf, удалив " опросы / " из каждой строки, и удалив строки, относящиеся к админке:
urlpatterns = patterns('mysite.polls.views', (r'^$', 'index'), (r'^(?P\d+)/$', 'detail'), (r'^(?P\d+)/results/$', 'results'), (r'^(?P\d+)/vote/$', 'vote'), )
Идея,стоящая за декаплингом include() и URLconf состоит в том, чтобы облегчить подключение и работу с URLs. Теперь, когда опросы находятся в их собственном URLconf, они могут быть размещены в " / опросы / ", или в "/fun_polls / ", или в "/content/polls / ", или в любом другом корневом URL, и приложение будет ещё работать.
Для приложения Опроса важны его относительные, а не абсолютные URL-адреса.
Перевод хостинг КОМТЕТ komtet.ru
Вам также может помочь
Ваше первое Django-приложение, часть 1
В статье "Writing your first Django app, part 1" автор показывает на примере, как можно создать своё приложение с помощью Django для тех, кто это делает впервые.
Ваше первое Django-приложение, часть 2
В статье "Writing your first Django app, part 2" автор продолжает обучающий курс по созданию приложения с помощью Django для тех, кто это делает впервые.
Get object or 404 django как работает
Объясняю на примере. Пишем представление для лайков django + Ajax.
Нам уже знакомо, как это пишется, так как мы писали уже комментарии.
Но я кое-что не сказал вам, главное.
Теперь когда у вас есть представление от ранее написанного, давайте писать лайки, но смотреть на это под другим углом.
Обратите внимание, как называются уроки? Верно - профессионально учимся писать представления.
Вот на этом и заострим внимание на профессионализме.
Следите за моим рассуждением именно поиском логики мы заёмемся.
И главное понять, что никакой логики для нашего представления для языка пайтон и для джанго нет, ни джанго ни язык
ничего не знают о логике.
Но они хорошо могут делать определённые действия, при помощи методов.
Важно понять, что саму логику знает только сам программист и в тот момент. когда мы для себя решили, что при клике сердечно будет красным, значит это нравится, а белым, значит не нравится.
именно поэтому мы создаём переменную liked(нравится) и для себя определяем, только для себя, но никак не для джанго или языка.
liked = False - не нравится.
liked = True - нравится.
А дальше начинает работать обыденная техническая сторона, а именно методы, которые хорошо умеет делать джанго.
Сначала, что б вам не дурили голову люди, которые вам будут перечислять навыки программирования, которые вы должны приобрести.
Я вам скажу все это у нас уже имеется.
Мы заквасили бочку капусты, дальше себе думаем. что бы был сок и капкуста сохранилась нужно нажать её чем-то тяжёлым.
У нас в голове в нашей логике появляются два состояния придавлена крышка чем-то тяжелым или нет.
Это единственная логика, которая имеет значение, для сохранности капусты.
в программировании тоже самое можно выразить так:
cabbage_pressed = True (нажата)
cabbage_pressed = False (не нажата)
При этом заметьте, в программировании мы не создаём вторую переменную , нам достаточно булевых значений TRUE (в любой ситуации ДА) - истина, FALSE - ложь (В любой ситуации НЕТ)
Вернёмся к бочке с капустой, далее думать не нужно, дальше вы нажимаете, тем что есть под рукой, камнем, автомобильным диском, гирей спортивной.
У вас в голове, есть, что - пойти и найти то чем нажать.
Ни бочка(язык), не капуста(джанго), ни гиря ничего не знают о чём вы думаете и о ваших планах сохранить капусту.
Теперь смотрите на код.
# @login_required def like_post(request): post = get_object_or_404(Post, # не понравилось liked = False if post.likes_post.filter(id=request.user.id).exists(): post.likes_post.remove(request.user) liked = False- post - это наша переменная, которая извлечёт статью нужную нам.
- likes_post - это поле нашей модели Post(есть в уроках в школе, здесь не поясняю, что бы не путать)
- но для представления анатомию модели джанго можете прочитать сейчас в моей группе в vk
- vk.com/@django_spb_tut-anatomiya-modeli-v-django-4
- далее обычная выборка с модели, есть в джанго модель, которая умеет выбирать разными способами, эти способы называются методами класса QuerySet(мы уже о нём говорили)
- filter() https://docs.djangoproject.com/en/4.1/ref/models/querysets/#filter
- Возвращает новый QuerySetсодержащие объекты, соответствующие заданному поиску параметры.
- А в поиске мы задаём - id пользователя. Что бы определить, кто кликает по картинке.
- сами найдите exists(). То есть найти кровь с носу.
ранее мы точно поределили пользователя, Далее все просто, мы точно знаем, что нам нужно удалить запись,
вот и добавляем.
нашу переменную post(все как ранее)
указываем таблицу модели.
и стандартный метод Джанго, который умеет удалять remove()
post.likes_post.remove(request.user)
liked = False
likes_post = models.ManyToManyField(
User, related_name='post_likes', blank=True, verbose_name='Лайки')
Соотвественно далее мы напишем с участниками ещё один кусок кода, где нужно будет добавить.
Нам осталось ещё немного, для полного понимания.
А именно, зачем нам Ajax.
Мы себе думаем, что нам хотелось бы, что бы лайк ставился без перезагрузки страницы.
В данном случае будем делать с Jquery.
Js будем учить работать с питон.
Js это совсем тупое создание, так что короткий поводок.
Но есть умное создание Jquery
нам нужно написать функцию по шаблону и разместить код в html, здесь не буду перегружать. а расскажу суть, будет больше пользы.
Что нам нужно от JS, нам нужна одна вещь,
- Передать данные на сервер, без перезагрузки страницы. как раз это и делает ajax.
- нам нужно что бы все срабатывало только по клику в определённом месте, то есть по клику по картинке сердечка.
- Нет ничего сложного, нам нужно грубо говоря придумать любое слово понятное нам, разместить это слово на странице, где картинка и сказать js что передовать данные сервер, только если кликают внутри этого слова (вернее тега)
- вот как это выглядит. like-section это и есть то слово, которое мы придумали и заключили в тег
и как вы видите внутри есть файл, а все просто, ранее мы создавали файл с картинками, мы его просто импортируем в страницу. которая показывает саму статью и вставляем под постом.
- Далее нам просто нужно описать условия для ajax, указать нашу форму, указать, что ждать и пока не кликнет человек ничего не делать. все это в уроках
- Остался последний вопрос, как будут взаимодейтсвовать Python и JS, через json
Здесь нет проблем.
JS будет работать так как он умеет используя свои типы данных, а питон, вернее Джанго,
заберёт эти данные, при помощи загатовленного ранее метода JsonResponse(), который есть в джанго и он умеет переводить данные. которые в формате json в типы данных питон.
нам просто нужно добавить в нашу функции такой код.
if request.is_ajax():
html = render_to_string('blog/like_section.html',
context,
request=request)Примечание. В джанго 4 убрали метод is_ajax(), но все же я считаю. что Jquery недооцененная библиотека, и я решил написать middleware, который вернул Джанго эту функцию.
Мы будем делать и другими способами, но я подумал. пусть у ребят будет и этот способ, он очень простой и пишется в пару строк.
middleware, что это и как работает рассказал здесь, точно уловите принцип
Нам осталось понять. как этот весь механизм запуститься.
когда пользователь попадёт на url неважно как, по ссылке, с поиска и т .д
сначала откроется по ссылке сама статья блога
path('post//', views.post_detail_view, name='post-detail'),
А вот картинка наше сердечко будет иметь свою ссылку, известную только нам и JS, по этой ссылке будут передаваться данные на сервер
path('post/like/', views.like_post, name='post-like'),
как видите есть наша функция
views.like_post. при наборе url она сработает
Ну и стоит обратить внимание на начало функции:
видите request здесь об этом говорил
Что нужно знать джанго о сервере она сама извлечёт при помощи HttpRequest.(загаловок, адрес, куки и т .д все что необходимо знать о странице, для нормальной работы)
и при этом сам пост не будет об этом ничего знать, помните, как я вас учил.
Мой вопрос. Кто знает логику? ваш ход.
Как я начала программировать добавить статью:
Посмотрите видео в описании есть ссылки на статью и прочтите больше будете понимать и быстрее начнёте писать:
Рекомендуется оценить мощь. Обязательно глянь подборку видео, как растут ребята, у тебя тоже получится.
Подборка видео, для прорыва в мозгах, изменит подход к изучению программирования.
здесь с ребятам я занимаюсь бесплатно в группе, направляю, кто хочет. все получается. Ведь какая проблема у новичка, он не знает на что уделить внимание, что бы программировать, а у меня на этом построена школа, то есть школа может быть полезна, даже если вы где-то учитесь, просто увеличите эффективность. когда будете понимать. как изучать программирование и язык не имеет значения.
что мне делать?
Купите доступ и учитесь, все получится. сами убедились, что действия, как в программировании вы делаете каждый день, так в чём проблема.
Только в одном. К программированию нужно подходить особым образом, вы уже наверное смотрели, что это значит и как:
Купить.
Джанго + Питон:
Либо Джанго + Питон + Блокчейн:
(Хит продаж) Внизу страницы 400 BYN:
Обучение программированию по индивидуальной программе.(очень круто)
Групповые занятия по программированию(весело и круто).