Pull to refresh

Comments 56

Все отлично сказал, но django-CMS в обиду не дадим!
Вообще то для веб приложений(тем более c i18n) она не подходит. Да.
Приходите к нам копирайтером работать, посмотрю что вы скажете через месяц Django-CMS :)
А что не так с django-cms? И, самое главное, почему это должно заботить копирайтеров?
нам абсолютно не подошел в работе. Крайне неудобен и сильно ограничивает гибкость, например, iframe/javascript не добавить на страницу.

Личное мнение, мы попробовали dbtemplates и Django CMS. Первый победил для нас по удобству.
Что мешает добавить свой виджет в Django CMS, который хоть iframe, хоть google maps выводит?
Лично мне Django CMS не понравился по скорости и огромному количеству запросов к базе.
Да это решение, но мне больше понравилось редактировать шаблоны на прямую. Супер-гибко, быстро и понятно.
Обычно это бывает, когда забываешь настроить локаль.
> Личное мнение, мы попробовали dbtemplates и Django CMS. Первый победил для нас по удобству.
Вот теперь вполне корректно :)
dbtemplates для профессионалов(копирайтеров и т.д.),
Django CMS для заказчиков.
Ну что вы! Для истинных профессионалов только notepad.exe и ручное (читай — качественное) редактирование страниц!
Я думаю, вы его неправильно готовили. В первую очередь это моё мнение обусловлено тем, что Вы рядом упомнинаете dbtemplates и cms. Мало того, что эти приложения совершенно разного уровня, так они ещё и ничего общего по функциональному назначению не имеют. Конечно, если использовать cms как хранилище шаблонов, ничего путного не выйдет.

Не буду разоряться на тему dbtemplates, оно простое, как две копейки и особого упоминания не заслуживает, по-моему, хотя у меня оно используется довольно часто. Лучше поразоряюсь на тему cms.

Соглашусь с тем, что редактирование страницы (не дерева, а именно страницы) в cms неочевидно и по первости может вызывать ступор. Она (страница редактирования) больше подходит для разработчиков, даже не просто подходит, она для них и предназначена. Пожалуй, вы сами виноваты: вы начали использование cms прежде чем попытались вникнуть в его философию.

Просто скажу, что:

  • При правильном подходе ситуация, когда контент редактируется в админке страницы, не обязательна. В неё можно вообще не заходить. Если, конечно, об этом позаботится
  • А копирайтерам для редактирования контента, можно в админку даже не заходить, а править всё прямо на сайте.
Про гибкость — я даже и не знаю, что на такое отвечать. Конечно, django-cms не идеален, но если оно не гибкое, то что же тогда гибкое?

Про ифреймы и js не понял. Почему не вставить? Кто запретит?
Я не хочу развивать флейм и доказывать свою точку зрения.

Мы в течении длительного количества времени (1 год/3 месяца) пользовались обоими решениями. Лично для нас dbtemplates оказались удобнее.

Если совсем абстрагироваться, решают они одну и ту же задачу — быстрое создание админки для контента.

iframe и js режется в Text-plugin DjangoCMS
Вы что, целых 15 месяцев пользовались django-cms в качестве редактора простеньких страничек? Если это так, то я вашу неприязнь понимаю и целиком разделяю: есть и более достойные решения редактирования контента.

С другой стороны, редактировать с помощью django-cms контент и при этом не пользоваться идущими из коробки мультиязычностью (привет, localurl!), поддержку меню и хлебных крошек (привет, костыльный treemenus!) и системой плагинов (привет любителям редактировать контент в свойствах страницы) — это дикость, я считчаю.

Извините.
12 месяцев и до сих пор используем, нет ресурсов на переписывание.

Еще раз повторюсь, что лично мне DjangoCMS не подошел. Вам подходит — используйте :) UMI.CMS тоже, говорят, хорошая штука.
Да понятно, что буду использовать :)

За державу обидно просто: прочтёт кто-нибудь статью, отложится у него в голове, что django-cms ад, ну и наговнокодит велосипедов. Или, что тоже возможно, начнёт эту же точку зрения в массы продвигать по старому доброму принципу: «я Пастернака не читал, но осуждаю».

И да, если не секрет, какую версия цмски используете, не 2.0.х, случайно?
Использование небольших, простых, независимых приложений — это не велосипедизм и не дикость, а очень разумный подход к архитектуре. Это ж замечательно, когда приложение настолько простое, что о нем даже упоминать не стоит.
Вы мой кумир и спорить сочту богохульством :)

Ни в коем случае не против независимых приложений. Велосипедизм тоже люблю, если в приделах разумного. Но я про другое немного. В посте описано три задачи, на которые хотелось бы обратить внимание: редактирование контента страницы, редактирование структуры сайта и меню, выбор языка.

DBTemplates предоставляет простейший функционал — хранение и редактирование Django шаблонов в базе данных… Это простое решение полностью удовлетворило наши потребности в изменении текстов на сайте

С первой задачей вроде справились: контент вбивается в модель dbtemplate (непонятно, правда, откуда django знает, какой шаблон рендерить. Имя шаблона строится по соглашению? Прошу пояснений junk).

Пока мы не доделали одну мелочь — редактирование меню и создание новых страниц, но думаю, django-treemenus вполне справится с этой задачей
Вторую реализовывать пока не стали, обозвав мелочью. Я с этим определением не согласен: чисто субъективно, задача навигации и всякого рода меню (тех же бредкрамбсов) — одна из самых мутных и труднореализуемых в джанге. Красивое решение видел только одно, о котором ниже. Если есть что-то достойное против костылей а-ля treemenu, буду очень рад узнать.

Да и вообще, чего получается-то: девчонкам, которые будут вбивать контент, придётся руками рисовать меню? HTML-тегами или тегами django, но руками? Если да, то опять же, чисто субъективно, решение не представляет никакого интереса.

И последнее на сегодня приложение django-localeurl. Оно решает простую задачу — язык сайта определяется исключительно из ссылки.
Тоже с успехом сделали.

А теперь посмотрим на django-cms. Она изначально задумана для решения такого рода задач. Там есть и встроенное редактирование контента страницы, и управление структурой отличное. И localeurl из коробки идёт. То есть один комплекс решает все мелкие задачи, при этом избавляя от рутины и непоняток (см. примечание про редактирование меню девчонками).

Неужели более логично заюзать кучу мелких несвязанных приложений, чем несколько приложений покрупнее, но тесно интегрированных друг с другом?
миш, мне изменяет память или ты по-первости сам плевался на django-cms, когда мы только начинали с ней работать? .)
Не изменяет. Что поделаешь, молод был, глуп.
пока не прикрутили treemenus все страницы забиваются через genericviews

Как прикрутим, будет ссылка из treemenus на редактирование шаблона.
dbtemplates — отличная идея, спасибо!
Вообще то самый большой минус Django — интернализация (надеюсь правильно написал). Не видел нормальных модулей для сабжа, что б был доступ для модели только для переводчика, копирайтера. Подскажите, хабровчане, пожалуйста.
UFO just landed and posted this here
Особенности интернализации Django — это не минус, а специализация. Это не CMS, а фреймворк, который хорошо подходить под нестандартные архитектурные решения и высокую нагрузку.

А если говорить про права, то у него очень гибкая система их настройки. Почитайте по ссылке выше от bobry
Молодцы!

Вообще, имеет ли смысл пытаться собрать каталог удачных модулей для джанго с рейтингом и комментами, как думаете? Может уже есть что-то подобное.
Я всегда буду обновлять страницу перед отправкой комментария.
А я не буду. У меня интернет медленный.
Мне, кажется, формат постов на Хабре более подходящий для обмена опытом.

Он не ограничен конкретно приложениями, можно делиться другими best-practice, ну и самое важное личные впечатления.
Можно тогда какой-нить тег для постов тогда придумать, чтобы их легче было искать среди джанго-постов ;)
Отличная статья! Не знал некоторых приложений. Буду смотреть.
Онотолий, тебя не тошнит от запросов, которые делает reversion? нравится видеть по 3 — 4 запроса на темплейты там, где можно в базаду не вообще не лазить? может еще и сессии в базе держите?
Витя, я если честно даже не смотрел что-там reversion делает, ни разу им не пользовался.
Мне понравилось что он есть из-коробки, авось пригодится.

Спасибо, за совет, вырублю его. Как писал выше, темплейты раз в час сбрасываются на диск.

Сессии держим в базе, да. На ресурсах с <500 уников в день, я об этом даже не задумываюсь.
Для ресурсов которые предполагают трафик, нужен совершенно другой подход и это не тот случай.
А зачем хранить шаблоны в базе?
Вот даже по теоретическому смыслу: база — это данные (модель), шаблоны — это представление (вьюха).
Чисто практически шаблоны ближе к програмному коду, поэтому их удобее держать в системе контроля версий. Вы их так часто меняете? Поправили на тестовой версии, проетистировали, перенесли в бой.
Убила идея инхронизации шаблонов на диск из базы раз в час. Наверное, навеяно идеями Continuous Integration? Это по-моему за гранью добра и зла. А если у вас в этот момент у вас кто-то правит шаблон и допустил ошибку? Сайт сломается на час?
Извините, но вы из прекрасной Django делаете какую-то мерзкую Zopu :)
Тексты у нас на проекте может менять любой сотрудник. Причем с моментальной обратной связью (шаблоны читаются с БД). За два месяца мы переписали все тексты два раза. Причем, кто-то пишет основу, другие правят орфографию и пунктуацию.

Ваше предложение с тестом и эсвээном НАМ абсолютно не подходит. Дергать девелоперов каждый раз, чтобы поправить запятую это бред.

И повторю еще раз. Не зависимо от технической красоты решения. Это удобно для НАС при экспуатации. Мы решаем бизнес-задачи.
Мы с вами под словами «шаблоны» и «контент» понимаем одно и тоже?
не знаю :)

Для меня шаблоны нижнего уровня (которые наследуют но не наследуются) = контент.

И очень удобно его править именно в шаблонах, я могу использовать все template filters. И как, мне кажется, создатели Django со мной солидарны, в шаблонах минимум логики и вся она про представление информации.

Какие фильтры и теги мы используем сейчас:
— url
— rur вставляет знак рубля
— include
— форматирование чисел через i18n {{ 10000 }}
— различные переменные из settings и других ContextProcessors
Тоже используем Rosetta в своем проекте. Отличная штука!
Класс, спасибо! Заменю свое самопальное приложение.
Как у вас работает словарь «состояние заявки», где статусы дублируются? Можете пояснить как вы с этим работаете?
неправильно описал этот словарь. Это граф возможных переходов состояний заявки.

По нему кнопочки в админке рисуются и проверяется возможность перехода.
Если это граф, то он получается не направленный?
почему? Вполне себе направленный.

'new': ['owned', 'cancelled'],

Это значит что из узла «new» можно перейти в узлы «owned», «cancelled».
А «cancelled» например из «feedback» и из вашего примера это одна и та же точка или вы еще храните историю переходов?
Мы храним всю историю, вот пример.
Гхм, не так картинка
И допустим после оценки если происходит «отмена» все в обратном порядке разворачивается?
Нет, смотрим на словарь

'cancelled': []

из состояния отмена деться никуда нельзя.
Спасибо за ваши пояснения, интересный подход!
Sign up to leave a comment.

Articles