Comments 7
Интересно было прочитать. Спасибо
Почему был выбран путь хранения шаблонов в каждом отдельном приложении? Чем это лучше/хуже создание отдельных директорий под каждое в project/templates/?
По сути, без разницы, где хранить статику и шаблоны. Но мне, например, удобней, чтобы директива templates была внутри приложения. А в корневой каталог были вынесены только base-шаблоны, как показал автор. Захотел удалить приложение — удали одну папку, откати settings.py и маршрутизацию в urls — и готово.
Оф. документация на djangoproject как раз даёт ответ на этот вопрос, в своём обучающем курсе по созданию приложения polls.
Насколько помню, они за универсальные приложения, которые можно переносить на другие проекты. Хранение всех файлов в папке приложения позволяет достичь этого.
А у кого-нибудь получилось это приложение запустить? Ни одна из таблиц зарегистрированных 4х приложений не создалась при миграции (только стоковые от фреймворка), как исход: первый запуск на localhost и 25 экспепшенов. Самый первый отсылает к таблице users_profile, которой нет в бд.
Мне кажется, что подход к генерации слагов не совсем правильный. Ведь нет особого смысла в тегах kotiki1 и kotiki2, когда и так уже есть kotiki.
Поэтому я бы просто запретил использование в тегах символов, которые удаляются при создании слага. И тогда уникальность слага будет обеспечиваться уникальностью тега, и подобная автонумерация просто не понадобится. То есть делал проверку уникальности по слагам.
Хотя конечно тег котики с русской o и кoтики с латинской пройдут проверку на уникальность, но дадут один и тот же слаг. Но в этом случае мне всё равно кажется неправильным добавлять номер. Я бы тогда просто счел второй тег не новым, а уже существующим.
Создаем блог на Django с опросами и тестами. Краткая инструкция. Часть 1