Comments 56
Да этоже поне с говнокода ^_^
Это полу-официальный символ Django.
webcache.googleusercontent.com/search?hl=ru&q=cache%3Ahttp%3A%2F%2Fdjangoadvent.com%2F1.2%2Fdjango-pony-retrospective%2F&aq=f&aqi=&aql=&oq=
webcache.googleusercontent.com/search?hl=ru&q=cache%3Ahttp%3A%2F%2Fdjangoadvent.com%2F1.2%2Fdjango-pony-retrospective%2F&aq=f&aqi=&aql=&oq=
срёт красным
Все отлично сказал, но django-CMS в обиду не дадим!
Вообще то для веб приложений(тем более c i18n) она не подходит. Да.
Вообще то для веб приложений(тем более c i18n) она не подходит. Да.
Приходите к нам копирайтером работать, посмотрю что вы скажете через месяц Django-CMS :)
А что не так с django-cms? И, самое главное, почему это должно заботить копирайтеров?
нам абсолютно не подошел в работе. Крайне неудобен и сильно ограничивает гибкость, например, iframe/javascript не добавить на страницу.
Личное мнение, мы попробовали dbtemplates и Django CMS. Первый победил для нас по удобству.
Личное мнение, мы попробовали dbtemplates и Django CMS. Первый победил для нас по удобству.
Что мешает добавить свой виджет в Django CMS, который хоть iframe, хоть google maps выводит?
Лично мне Django CMS не понравился по скорости и огромному количеству запросов к базе.
Лично мне Django CMS не понравился по скорости и огромному количеству запросов к базе.
> Личное мнение, мы попробовали dbtemplates и Django CMS. Первый победил для нас по удобству.
Вот теперь вполне корректно :)
dbtemplates для профессионалов(копирайтеров и т.д.),
Django CMS для заказчиков.
Вот теперь вполне корректно :)
dbtemplates для профессионалов(копирайтеров и т.д.),
Django CMS для заказчиков.
Я думаю, вы его неправильно готовили. В первую очередь это моё мнение обусловлено тем, что Вы рядом упомнинаете
Не буду разоряться на тему
Соглашусь с тем, что редактирование страницы (не дерева, а именно страницы) в
Просто скажу, что:
Про ифреймы и js не понял. Почему не вставить? Кто запретит?
dbtemplates и cms. Мало того, что эти приложения совершенно разного уровня, так они ещё и ничего общего по функциональному назначению не имеют. Конечно, если использовать cms как хранилище шаблонов, ничего путного не выйдет.Не буду разоряться на тему
dbtemplates, оно простое, как две копейки и особого упоминания не заслуживает, по-моему, хотя у меня оно используется довольно часто. Лучше поразоряюсь на тему cms.Соглашусь с тем, что редактирование страницы (не дерева, а именно страницы) в
cms неочевидно и по первости может вызывать ступор. Она (страница редактирования) больше подходит для разработчиков, даже не просто подходит, она для них и предназначена. Пожалуй, вы сами виноваты: вы начали использование cms прежде чем попытались вникнуть в его философию. Просто скажу, что:
- При правильном подходе ситуация, когда контент редактируется в админке страницы, не обязательна. В неё можно вообще не заходить. Если, конечно, об этом позаботится
- А копирайтерам для редактирования контента, можно в админку даже не заходить, а править всё прямо на сайте.
Про ифреймы и js не понял. Почему не вставить? Кто запретит?
Я не хочу развивать флейм и доказывать свою точку зрения.
Мы в течении длительного количества времени (1 год/3 месяца) пользовались обоими решениями. Лично для нас dbtemplates оказались удобнее.
Если совсем абстрагироваться, решают они одну и ту же задачу — быстрое создание админки для контента.
iframe и js режется в Text-plugin DjangoCMS
Мы в течении длительного количества времени (1 год/3 месяца) пользовались обоими решениями. Лично для нас dbtemplates оказались удобнее.
Если совсем абстрагироваться, решают они одну и ту же задачу — быстрое создание админки для контента.
iframe и js режется в Text-plugin DjangoCMS
Вы что, целых 15 месяцев пользовались django-cms в качестве редактора простеньких страничек? Если это так, то я вашу неприязнь понимаю и целиком разделяю: есть и более достойные решения редактирования контента.
С другой стороны, редактировать с помощью django-cms контент и при этом не пользоваться идущими из коробки мультиязычностью (привет, localurl!), поддержку меню и хлебных крошек (привет, костыльный treemenus!) и системой плагинов (привет любителям редактировать контент в свойствах страницы) — это дикость, я считчаю.
Извините.
С другой стороны, редактировать с помощью django-cms контент и при этом не пользоваться идущими из коробки мультиязычностью (привет, localurl!), поддержку меню и хлебных крошек (привет, костыльный treemenus!) и системой плагинов (привет любителям редактировать контент в свойствах страницы) — это дикость, я считчаю.
Извините.
12 месяцев и до сих пор используем, нет ресурсов на переписывание.
Еще раз повторюсь, что лично мнеDjangoCMS не подошел. Вам подходит — используйте :) UMI.CMS тоже, говорят, хорошая штука.
Еще раз повторюсь, что лично мне
Да понятно, что буду использовать :)
За державу обидно просто: прочтёт кто-нибудь статью, отложится у него в голове, что django-cms ад, ну и наговнокодит велосипедов. Или, что тоже возможно, начнёт эту же точку зрения в массы продвигать по старому доброму принципу: «я Пастернака не читал, но осуждаю».
И да, если не секрет, какую версия цмски используете, не 2.0.х, случайно?
За державу обидно просто: прочтёт кто-нибудь статью, отложится у него в голове, что django-cms ад, ну и наговнокодит велосипедов. Или, что тоже возможно, начнёт эту же точку зрения в массы продвигать по старому доброму принципу: «я Пастернака не читал, но осуждаю».
И да, если не секрет, какую версия цмски используете, не 2.0.х, случайно?
Использование небольших, простых, независимых приложений — это не велосипедизм и не дикость, а очень разумный подход к архитектуре. Это ж замечательно, когда приложение настолько простое, что о нем даже упоминать не стоит.
Вы мой кумир и спорить сочту богохульством :)
Ни в коем случае не против независимых приложений. Велосипедизм тоже люблю, если в приделах разумного. Но я про другое немного. В посте описано три задачи, на которые хотелось бы обратить внимание: редактирование контента страницы, редактирование структуры сайта и меню, выбор языка.
С первой задачей вроде справились: контент вбивается в модель dbtemplate (непонятно, правда, откуда django знает, какой шаблон рендерить. Имя шаблона строится по соглашению? Прошу пояснений junk).
Да и вообще, чего получается-то: девчонкам, которые будут вбивать контент, придётся руками рисовать меню? HTML-тегами или тегами django, но руками? Если да, то опять же, чисто субъективно, решение не представляет никакого интереса.
А теперь посмотрим на django-cms. Она изначально задумана для решения такого рода задач. Там есть и встроенное редактирование контента страницы, и управление структурой отличное. И localeurl из коробки идёт. То есть один комплекс решает все мелкие задачи, при этом избавляя от рутины и непоняток (см. примечание про редактирование меню девчонками).
Неужели более логично заюзать кучу мелких несвязанных приложений, чем несколько приложений покрупнее, но тесно интегрированных друг с другом?
Ни в коем случае не против независимых приложений. Велосипедизм тоже люблю, если в приделах разумного. Но я про другое немного. В посте описано три задачи, на которые хотелось бы обратить внимание: редактирование контента страницы, редактирование структуры сайта и меню, выбор языка.
DBTemplates предоставляет простейший функционал — хранение и редактирование Django шаблонов в базе данных… Это простое решение полностью удовлетворило наши потребности в изменении текстов на сайте
С первой задачей вроде справились: контент вбивается в модель dbtemplate (непонятно, правда, откуда django знает, какой шаблон рендерить. Имя шаблона строится по соглашению? Прошу пояснений junk).
Пока мы не доделали одну мелочь — редактирование меню и создание новых страниц, но думаю, django-treemenus вполне справится с этой задачейВторую реализовывать пока не стали, обозвав мелочью. Я с этим определением не согласен: чисто субъективно, задача навигации и всякого рода меню (тех же бредкрамбсов) — одна из самых мутных и труднореализуемых в джанге. Красивое решение видел только одно, о котором ниже. Если есть что-то достойное против костылей а-ля treemenu, буду очень рад узнать.
Да и вообще, чего получается-то: девчонкам, которые будут вбивать контент, придётся руками рисовать меню? HTML-тегами или тегами django, но руками? Если да, то опять же, чисто субъективно, решение не представляет никакого интереса.
И последнее на сегодня приложение django-localeurl. Оно решает простую задачу — язык сайта определяется исключительно из ссылки.Тоже с успехом сделали.
А теперь посмотрим на django-cms. Она изначально задумана для решения такого рода задач. Там есть и встроенное редактирование контента страницы, и управление структурой отличное. И localeurl из коробки идёт. То есть один комплекс решает все мелкие задачи, при этом избавляя от рутины и непоняток (см. примечание про редактирование меню девчонками).
Неужели более логично заюзать кучу мелких несвязанных приложений, чем несколько приложений покрупнее, но тесно интегрированных друг с другом?
спасибо, не знал о rosetta и dbtemplates!
dbtemplates — отличная идея, спасибо!
Вообще то самый большой минус Django — интернализация (надеюсь правильно написал). Не видел нормальных модулей для сабжа, что б был доступ для модели только для переводчика, копирайтера. Подскажите, хабровчане, пожалуйста.
UFO just landed and posted this here
Особенности интернализации Django — это не минус, а специализация. Это не CMS, а фреймворк, который хорошо подходить под нестандартные архитектурные решения и высокую нагрузку.
А если говорить про права, то у него очень гибкая система их настройки. Почитайте по ссылке выше от bobry
А если говорить про права, то у него очень гибкая система их настройки. Почитайте по ссылке выше от bobry
интернационализация
Молодцы!
Вообще, имеет ли смысл пытаться собрать каталог удачных модулей для джанго с рейтингом и комментами, как думаете? Может уже есть что-то подобное.
Вообще, имеет ли смысл пытаться собрать каталог удачных модулей для джанго с рейтингом и комментами, как думаете? Может уже есть что-то подобное.
Есть же djangopackages
Мне, кажется, формат постов на Хабре более подходящий для обмена опытом.
Он не ограничен конкретно приложениями, можно делиться другими best-practice, ну и самое важное личные впечатления.
Он не ограничен конкретно приложениями, можно делиться другими best-practice, ну и самое важное личные впечатления.
Отличная статья! Не знал некоторых приложений. Буду смотреть.
Онотолий, тебя не тошнит от запросов, которые делает reversion? нравится видеть по 3 — 4 запроса на темплейты там, где можно в базаду не вообще не лазить? может еще и сессии в базе держите?
Витя, я если честно даже не смотрел что-там reversion делает, ни разу им не пользовался.
Мне понравилось что он есть из-коробки, авось пригодится.
Спасибо, за совет, вырублю его. Как писал выше, темплейты раз в час сбрасываются на диск.
Сессии держим в базе, да. На ресурсах с <500 уников в день, я об этом даже не задумываюсь.
Для ресурсов которые предполагают трафик, нужен совершенно другой подход и это не тот случай.
Мне понравилось что он есть из-коробки, авось пригодится.
Спасибо, за совет, вырублю его. Как писал выше, темплейты раз в час сбрасываются на диск.
Сессии держим в базе, да. На ресурсах с <500 уников в день, я об этом даже не задумываюсь.
Для ресурсов которые предполагают трафик, нужен совершенно другой подход и это не тот случай.
А зачем хранить шаблоны в базе?
Вот даже по теоретическому смыслу: база — это данные (модель), шаблоны — это представление (вьюха).
Чисто практически шаблоны ближе к програмному коду, поэтому их удобее держать в системе контроля версий. Вы их так часто меняете? Поправили на тестовой версии, проетистировали, перенесли в бой.
Убила идея инхронизации шаблонов на диск из базы раз в час. Наверное, навеяно идеями Continuous Integration? Это по-моему за гранью добра и зла. А если у вас в этот момент у вас кто-то правит шаблон и допустил ошибку? Сайт сломается на час?
Извините, но вы из прекрасной Django делаете какую-то мерзкую Zopu :)
Вот даже по теоретическому смыслу: база — это данные (модель), шаблоны — это представление (вьюха).
Чисто практически шаблоны ближе к програмному коду, поэтому их удобее держать в системе контроля версий. Вы их так часто меняете? Поправили на тестовой версии, проетистировали, перенесли в бой.
Убила идея инхронизации шаблонов на диск из базы раз в час. Наверное, навеяно идеями Continuous Integration? Это по-моему за гранью добра и зла. А если у вас в этот момент у вас кто-то правит шаблон и допустил ошибку? Сайт сломается на час?
Извините, но вы из прекрасной Django делаете какую-то мерзкую Zopu :)
Тексты у нас на проекте может менять любой сотрудник. Причем с моментальной обратной связью (шаблоны читаются с БД). За два месяца мы переписали все тексты два раза. Причем, кто-то пишет основу, другие правят орфографию и пунктуацию.
Ваше предложение с тестом и эсвээном НАМ абсолютно не подходит. Дергать девелоперов каждый раз, чтобы поправить запятую это бред.
И повторю еще раз. Не зависимо от технической красоты решения. Это удобно для НАС при экспуатации. Мы решаем бизнес-задачи.
Ваше предложение с тестом и эсвээном НАМ абсолютно не подходит. Дергать девелоперов каждый раз, чтобы поправить запятую это бред.
И повторю еще раз. Не зависимо от технической красоты решения. Это удобно для НАС при экспуатации. Мы решаем бизнес-задачи.
Мы с вами под словами «шаблоны» и «контент» понимаем одно и тоже?
не знаю :)
Для меня шаблоны нижнего уровня (которые наследуют но не наследуются) = контент.
И очень удобно его править именно в шаблонах, я могу использовать все template filters. И как, мне кажется, создатели Django со мной солидарны, в шаблонах минимум логики и вся она про представление информации.
Какие фильтры и теги мы используем сейчас:
— url
— rur вставляет знак рубля
— include
— форматирование чисел через i18n {{ 10000 }}
— различные переменные из settings и других ContextProcessors
Для меня шаблоны нижнего уровня (которые наследуют но не наследуются) = контент.
И очень удобно его править именно в шаблонах, я могу использовать все template filters. И как, мне кажется, создатели Django со мной солидарны, в шаблонах минимум логики и вся она про представление информации.
Какие фильтры и теги мы используем сейчас:
— url
— rur вставляет знак рубля
— include
— форматирование чисел через i18n {{ 10000 }}
— различные переменные из settings и других ContextProcessors
Тоже используем Rosetta в своем проекте. Отличная штука!
> autologin-token
Гляньте это приложение bitbucket.org/lorien/django-urlauth/src/94c3fa013950/urlauth/tests.py
Гляньте это приложение bitbucket.org/lorien/django-urlauth/src/94c3fa013950/urlauth/tests.py
Как у вас работает словарь «состояние заявки», где статусы дублируются? Можете пояснить как вы с этим работаете?
неправильно описал этот словарь. Это граф возможных переходов состояний заявки.
По нему кнопочки в админке рисуются и проверяется возможность перехода.
По нему кнопочки в админке рисуются и проверяется возможность перехода.
Если это граф, то он получается не направленный?
Sign up to leave a comment.
Django проект PR Hero: что внутри и полученный опыт