Простой блог с комментариями на Django: разработка и развертывание для самых маленьких

[Zagrebelion]

Сделайте простой миксин

class PostMixin(object):
    model = Post

и вьюшки станут ещё проще:

class PostsListView(PostMixin, ListView): # представление в виде списка
    pass

class PostDetailView(PostMixin, DetailView): # детализированное представление модели
    pass

[svfat]

Я бы не сказал, что этот прием значительно улучшит читаемость кода.

[Zagrebelion]

В статье для начинающих, стоит упомянуть про миксины и дать ссылку на django-braces. Тогда на вопрос «зачем вообще нужны CBV» будет легче ответить, кмк.

[svfat]

Согласен, в статье многого не упомянуто и не раскрыто. Ее идея именно в том, что бы человек переписал код и сразу получил более-менее функционирующий прототип, ведь порой скучно изучать только теорию, не применяя знания на практике. Однако, как часто бывает на Хабре, комментарии к статье становятся полезнее самой статьи. Так что, думаю, пытливые умы дойдут до Вашего комментария и ознакомятся с mixins, за что Вам огромное «Спасибо»!

[idle]

В самой статье для начинающих про «примеси» не должно быть ни слова ;)

[stalkerg]

Тем более правильнее это назвать — множественное наследование. В python нету миксинов аля JS или Ruby.

[Archarious]

Я просто оставлю здесь своё «Спасибо!». Эта статья мне очень пригодится через пару недель!

[Pandorin]

И как результат? :)

[Vlad_IT]

del

[barker]

Почему django.contrib.staticfiles вроде как заявлен, а не используете как положено? Вообще какой-то странный подход к статике у вас. Для остальных аппов в дальнейшем тоже ручками будете всё прописывать, да? Или я что-то не понял?

Редактируем settings.py, что бы Django знало где искать статические страницы.
STATICFILES_DIRS = (
os.path.join(BASE_DIR, 'static'),
)

Как раз джанге это не надо вообще знать, это информация для staticfiles, чтобы знать откуда собирать статику и информация для runserver, который из staticfiles (а не который из джанги родной), чтобы оно в девелоперском режиме статику могло раздавать.

[Zagrebelion]

для остальных аппов, как правило, прописан django.contrib.staticfiles.finders.AppDirectoriesFinder в STATICFILES_FINDERS, а вот для каких-то общепроектные вещей (тот же бутстрап, как у автора) лежит в корне проекта и не принадлежит ни одному приложению, поэтому для него нужен django.contrib.staticfiles.finders.FileSystemFinder и STATICFILES_DIRS.

[barker]

Это я всё знаю, но причём тут финдеры? Речь про то, как реальный сервер будет раздавать статику. Что автор и настраивает, собственно, вручную. Сервер не лазает через финдеры за статикой, очевидно. А то так-то и у аппа admin статика лежит обычным образом и AppDirectoriesFinder её, понятно дело, вполне видит, иначе бы runserver у автора не работал с этим приложением. Но настраивает автор его вручную как видите на боевом сервере, потому что ему приходится это делать, т.к. — см. информацию из моего соощения выше.

[Zagrebelion]

manage.py collectstatic.
Или у вас nginx (или что там статику отдаёт) лазает по всему джанго-проекту?

[barker]

Так а я про что, собственно, говорю? Вы или статью не прочитали, или меня, походу, с кем-то спутали. Я то тут причём. У меня как раз никто не лазает по всему проекту. А вот у автора непонятно что творится со статикой. Никаким collectstatic там не пахнет, т.к. статика для сервера напрямую натравливается на один из STATICFILES_DIRS (который по определению не должен быть STATIC_ROOT) и на папку глубоко внутри одного из используемых аппов. Я сказал что так никто не делает, а Вы начали рассказывать про Finder-ы, которые никаким боком тут не затрагиваются, что сами же подтвердили следующим комментарием про collectstatic.

[Zagrebelion]

Всё, увидел о чём вы говорите: три раза читал статью, и три раза фрагмент про статику на pythonanywhere проходил мимо восприятия.
Кстати, туториал на этом хостинге предлагает статику раздавать самой джангой. Очень странно.

[merlin-vrn]

Да сам хостинг сыроват ещё просто. Научатся :)

[barker]

Если вы про urlpatterns += staticfiles_urlpatterns(), то оно работает всё равно только при DEBUG=True, и по сути используется только для того же runserver. На боевом оно работать опять же НЕ БУДЕТ. Но вот зачем оно рассказывается там, да ещё с каментами типа «This is needed to serve static files like images and css», это я не знаю, абсурд какой-то)

[MechanisM]

Хороший туториал, только я бы порекомендовал не хардкодить ссылки в get_absolute_url а сделать reverse

[merlin-vrn]

В данном случае по-моему вообще лучше дать view имя (типа post-detail) и в шаблоне реверсить его с помощью {% url 'post-detail' post.pk %}

[MechanisM]

Я все-таки считаю что лучше получать url везде через get_absolute_url так получается более DRY и тем-более потом структура url и модели может поменяться, например добавится slug и в адресе появится не id а slug(или и то и другое), а get_absolute_url как работала так и будет работать. И править надо будет всего в одном месте. Шаблонов тоже может оказаться много.

[merlin-vrn]

Нет, не в одном. Придётся всегда синхронно делать изменения в модулях url и model. А так, как я предлагаю — поменял регэксп в модуле url, поменялся адрес, а шаблоны трогать не надо. И, кстати даже добавление slug не потребует менять шаблоны, если slug станет pk :) Это, правда, касается модели, но добавление slug — в любом случае вмешательство в модель.

[idle]

LANGUAGE_CODE = 'ru-ru'

Если строго, то ru-ru не бывает, судя по github.com/django/django/tree/master/django/conf/locale. Пока просто ru.

[johnnythekid]

Спасибо за статью. Если бы не Вы, я бы так и не добрался до джанго.

[col]

Огромный сенкс.
Однозначно в маст хэв

Только у меня почему то джанго отказывался искать шаблоны в папке templates,
пришлось прописать самому в setings.py

TEMPLATE_DIRS = (
    os.path.join(BASE_DIR, 'templates'),
)