Comments 24
Сделайте простой миксин
и вьюшки станут ещё проще:
class PostMixin(object):
model = Post
и вьюшки станут ещё проще:
class PostsListView(PostMixin, ListView): # представление в виде списка
pass
class PostDetailView(PostMixin, DetailView): # детализированное представление модели
pass
Я бы не сказал, что этот прием значительно улучшит читаемость кода.
В статье для начинающих, стоит упомянуть про миксины и дать ссылку на django-braces. Тогда на вопрос «зачем вообще нужны CBV» будет легче ответить, кмк.
Согласен, в статье многого не упомянуто и не раскрыто. Ее идея именно в том, что бы человек переписал код и сразу получил более-менее функционирующий прототип, ведь порой скучно изучать только теорию, не применяя знания на практике. Однако, как часто бывает на Хабре, комментарии к статье становятся полезнее самой статьи. Так что, думаю, пытливые умы дойдут до Вашего комментария и ознакомятся с mixins, за что Вам огромное «Спасибо»!
В самой статье для начинающих про «примеси» не должно быть ни слова ;)
Я просто оставлю здесь своё «Спасибо!». Эта статья мне очень пригодится через пару недель!
Почему django.contrib.staticfiles вроде как заявлен, а не используете как положено? Вообще какой-то странный подход к статике у вас. Для остальных аппов в дальнейшем тоже ручками будете всё прописывать, да? Или я что-то не понял?
Редактируем settings.py, что бы Django знало где искать статические страницы.Как раз джанге это не надо вообще знать, это информация для staticfiles, чтобы знать откуда собирать статику и информация для runserver, который из staticfiles (а не который из джанги родной), чтобы оно в девелоперском режиме статику могло раздавать.
STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'static'),
)
для остальных аппов, как правило, прописан
django.contrib.staticfiles.finders.AppDirectoriesFinder в STATICFILES_FINDERS, а вот для каких-то общепроектные вещей (тот же бутстрап, как у автора) лежит в корне проекта и не принадлежит ни одному приложению, поэтому для него нужен django.contrib.staticfiles.finders.FileSystemFinder и STATICFILES_DIRS.Это я всё знаю, но причём тут финдеры? Речь про то, как реальный сервер будет раздавать статику. Что автор и настраивает, собственно, вручную. Сервер не лазает через финдеры за статикой, очевидно. А то так-то и у аппа admin статика лежит обычным образом и AppDirectoriesFinder её, понятно дело, вполне видит, иначе бы runserver у автора не работал с этим приложением. Но настраивает автор его вручную как видите на боевом сервере, потому что ему приходится это делать, т.к. — см. информацию из моего соощения выше.
manage.py collectstatic.
Или у вас nginx (или что там статику отдаёт) лазает по всему джанго-проекту?
Или у вас nginx (или что там статику отдаёт) лазает по всему джанго-проекту?
Так а я про что, собственно, говорю? Вы или статью не прочитали, или меня, походу, с кем-то спутали. Я то тут причём. У меня как раз никто не лазает по всему проекту. А вот у автора непонятно что творится со статикой. Никаким collectstatic там не пахнет, т.к. статика для сервера напрямую натравливается на один из STATICFILES_DIRS (который по определению не должен быть STATIC_ROOT) и на папку глубоко внутри одного из используемых аппов. Я сказал что так никто не делает, а Вы начали рассказывать про Finder-ы, которые никаким боком тут не затрагиваются, что сами же подтвердили следующим комментарием про collectstatic.
Всё, увидел о чём вы говорите: три раза читал статью, и три раза фрагмент про статику на pythonanywhere проходил мимо восприятия.
Кстати, туториал на этом хостинге предлагает статику раздавать самой джангой. Очень странно.
Кстати, туториал на этом хостинге предлагает статику раздавать самой джангой. Очень странно.
Да сам хостинг сыроват ещё просто. Научатся :)
Если вы про urlpatterns += staticfiles_urlpatterns(), то оно работает всё равно только при DEBUG=True, и по сути используется только для того же runserver. На боевом оно работать опять же НЕ БУДЕТ. Но вот зачем оно рассказывается там, да ещё с каментами типа «This is needed to serve static files like images and css», это я не знаю, абсурд какой-то)
Хороший туториал, только я бы порекомендовал не хардкодить ссылки в get_absolute_url а сделать reverse
В данном случае по-моему вообще лучше дать view имя (типа post-detail) и в шаблоне реверсить его с помощью {% url 'post-detail' post.pk %}
Я все-таки считаю что лучше получать url везде через get_absolute_url так получается более DRY и тем-более потом структура url и модели может поменяться, например добавится slug и в адресе появится не id а slug(или и то и другое), а get_absolute_url как работала так и будет работать. И править надо будет всего в одном месте. Шаблонов тоже может оказаться много.
Нет, не в одном. Придётся всегда синхронно делать изменения в модулях url и model. А так, как я предлагаю — поменял регэксп в модуле url, поменялся адрес, а шаблоны трогать не надо. И, кстати даже добавление slug не потребует менять шаблоны, если slug станет pk :) Это, правда, касается модели, но добавление slug — в любом случае вмешательство в модель.
LANGUAGE_CODE = 'ru-ru'
Если строго, то ru-ru не бывает, судя по github.com/django/django/tree/master/django/conf/locale. Пока просто ru.
Спасибо за статью. Если бы не Вы, я бы так и не добрался до джанго.
Огромный сенкс.
Однозначно в маст хэв
Только у меня почему то джанго отказывался искать шаблоны в папке templates,
пришлось прописать самому в setings.py
Однозначно в маст хэв
Только у меня почему то джанго отказывался искать шаблоны в папке templates,
пришлось прописать самому в setings.py
TEMPLATE_DIRS = (
os.path.join(BASE_DIR, 'templates'),
)
Sign up to leave a comment.
Простой блог с комментариями на Django: разработка и развертывание для самых маленьких