Django — очаровательный в своей простоте и гибкости фреймворк. Однако, для быстрого построения большого числа несложных сайтов требуется поставить разработку сайтов на поток. Разрабатывать систему управления сайтом каждый раз утомляет и грозит потерями времени. Именно поэтому программисты часто обращаются к готовым CMS.
Почти все знают о гигантах конвеерного веб-программирования, основанных на php — Drupal, Joomla!, Wordpress и прочих, но не все знают, что в мире Python существуют не менее мощные и даже гораздо более зрелые инструменты.
Знающие мир Питона и не интересующиеся установкой могут сразу перейти к разделу Маленькие радости CMS.
Разговор о веб-приложениях на Питоне надо начинать с папы всех CMS и фреймворков: Zope. Его история тянется с лохматого 1998 года, фреймворк ("сервер приложений") включает собственную базу данных, в работе надо проектом принимал участие сам Гвидо Ван Россум, элементы и архитектурные решения фреймворка используются во многих других больших проектах (прежде всего Zope Component Architecture).
Вторым по значимости проектом можно считать Plone CMS (1999 года рождения), основанный на Zope. Plone широко известен чуть западней РФ; вокруг него даже сформировалась мини-индустрия построения сайтов (вроде той, что крутится на Drupal).
Последние годы ознаменовались тремя событиями в agile-вебостроении: настал MVC, приелся php и фактически заново родился Ruby.
Ruby on Rails, Django были анонсированы в 2005 году и ставили во главу угла общую идею: MVC в вебе быть, MVC (или как это называется в Джанго) в вебе рулить. На этой волне поднялся малоизвестный прежде Руби и ускорилась популяризация Питона в веб-разработке.
И, конечно, вспоминать о том, почему Питон и Руби уделывают php, просто не стоит.
Однако, Питон — язык универсальный; интересных фреймворков на нем больше (чего только Twisted стоит); история богаче. Поэтому лично я выбрал Питон (и, соответственно, Джанго) в качестве сначала вспомогательного скриптового языка, а затем, когда открылись все богатые его возможности, и основного.
Велосипедостроение — излюбленное занятие программистов. Все мы хотим контролировать процесс разработки на всех уровнях: это оставляет много места для подвигов и личного героизма.
Но наступает момент — и написание блога в совокупности с десятком статичных страниц (flatpages, если по-джанговски) начинает казаться чем-то лишним. В свой светлый миг я решил исследовать мир на предмет CMS, основанных на Django.
Оказалось, что выбор здесь следующий:
Из коробки наибольший функционал предоставлял DjangoCMS, именно поэтому первый
промышленный опыт решено было получать на нем.
Последнее веяние питоновской моды (если не необходимость) — использование среды virtualenv. Это "песочница", в которую устанавливаются все зависимости будущего проекта: сам интерпретатор, стандартный инструментарий, необходимые библиотеки. В нашем случае — Django и DjangoCMS.
Создадим директорию cms-project, в ней — среду virtualenv:
Теперь ставим django, DjangoCMS и PIL (Python Imaging LIbrary), находясь прямо в
той же дир-ии (cms-project):
Кстати, используется pip, который немного лучше обычного easy_install. Ключ -E и его аргумент указывают на директорию окружения, в которую раскладывается пакет. Теперь запустим окружение (по-прежнему находясь в cms-project):
Теперь находимся в окружении (env), нам доступны команды Django, установленного в окружение:
Корректируем, как обычно в Джанго, tstproj/settings.py (БД и прочие мелкие
радости). Подключаем админку, не забываем сделать в директории MEDIA_ROOT
симлинк на ее статику.
Проверяем работу фреймворка:
Теперь надо подключить django-cms. В общем-то, это просто. Надо лишь добавить процессоры контекста, само приложение, создать хотя бы один шаблон. Опять же, в MEDIA_ROOT — симлинк на статику cms, в settings.py — переменная с адресом cms. Создание симлинка в моем случае (вся статика — в директории tstproj/media/)
выглядит так:
Вуаля. Пробуем:
Заходим браузером в админку(по умолчанию http://localhost:8000/admin/), и — о, счастье! — попадаем в CMS.
Итак, что дает нам CMS.
В интерфейсе администратора появляется пункт "CMS" с подпунктом "Pages". Здесь
располагается сердце приложения — карта-дерево сайта. Можно подлючать страницы,
управлять их публикацией и включением в меню.
Создание каждой страницы начинается с указания шаблона. Шаблоны перечисляются в
переменной CMS_TEMPLATES в файле settings.py.
Шаблон — обычный для Джанго, со включенными тегами cms_tags. Главный тег — placeholder, указывающий места включения плагинов. Другие удобные теги — show_menu и breadcrumbs, позволяют включать в шаблон навигационное меню и "хлебные крошки". Внешний вид вспомогательных элементов легко регулируется в отдельных шаблонах.
Места, отмеченные тегом placeholder, из интерфейса администратора можно будет заполнить плагинами. Из коробки доступны плагины включения в страницу форматированного текста, ссылок, файлов, картинок, Google Map, кусков html.
Новые плагины создаются очень легко на базе имеющихся моделей, интерфейс управления содержимым плагина можно генерировать автоматически — как с обычными моделями Django.
Для человека, знакомого с разработкой на фреймворке очень удобно, что в карту сайта можно добавлять обычные приложения Джанго — и навигационное меню будет их учитывать. Приложения для этого надо зарегистрировать в settings.py:
Приложения также могут модифицировать поведение навигационного меню. Например, перечислять элементы каталога, разделы магазина и так далее.
Вот и все. Впрочем, большего лично мне и не надо.
А вот так, собственно, выглядит карта сайта:
![](http://www.django-cms.org/media/uploads/cms_page_media/2/3_pagelist___.png)
Волшебный WYSIWYG:
![](http://www.django-cms.org/media/uploads/cms_page_media/2/5_plugindetail___.png)
Редактирование страницы сайта:
![](http://www.django-cms.org/media/uploads/cms_page_media/2/4_pagedetail___.png)
Интерфейс администратора достаточно прост и его не стыдно показать заказчику сайта.
Плагинов и расширений пока немного, но веб-программисту не составит труда подключить любое из обычных приложений Django либо разработать новый компонент.
Нужно отметить внятную и удобную документацию.
В общем, DjangoCMS2.0 вполне подходит для людей, часто имеющих дело с Django и привыкшими к удобной разработке на Python.
UPD: Найти документацию по проекту, скачать пакет, найти плагины или расширения можно здесь
UPD2: Картиночки влепил с официального сайта по просьбам трудяг-программистов. Проверял лично — все так и выглядит.
Почти все знают о гигантах конвеерного веб-программирования, основанных на php — Drupal, Joomla!, Wordpress и прочих, но не все знают, что в мире Python существуют не менее мощные и даже гораздо более зрелые инструменты.
Знающие мир Питона и не интересующиеся установкой могут сразу перейти к разделу Маленькие радости CMS.
Ликбез
Разговор о веб-приложениях на Питоне надо начинать с папы всех CMS и фреймворков: Zope. Его история тянется с лохматого 1998 года, фреймворк ("сервер приложений") включает собственную базу данных, в работе надо проектом принимал участие сам Гвидо Ван Россум, элементы и архитектурные решения фреймворка используются во многих других больших проектах (прежде всего Zope Component Architecture).
Вторым по значимости проектом можно считать Plone CMS (1999 года рождения), основанный на Zope. Plone широко известен чуть западней РФ; вокруг него даже сформировалась мини-индустрия построения сайтов (вроде той, что крутится на Drupal).
Серверный веб последней волны
Последние годы ознаменовались тремя событиями в agile-вебостроении: настал MVC, приелся php и фактически заново родился Ruby.
Ruby on Rails, Django были анонсированы в 2005 году и ставили во главу угла общую идею: MVC в вебе быть, MVC (или как это называется в Джанго) в вебе рулить. На этой волне поднялся малоизвестный прежде Руби и ускорилась популяризация Питона в веб-разработке.
И, конечно, вспоминать о том, почему Питон и Руби уделывают php, просто не стоит.
Однако, Питон — язык универсальный; интересных фреймворков на нем больше (чего только Twisted стоит); история богаче. Поэтому лично я выбрал Питон (и, соответственно, Джанго) в качестве сначала вспомогательного скриптового языка, а затем, когда открылись все богатые его возможности, и основного.
Django + DjangoCMS2.0 — как они есть
Велосипедостроение — излюбленное занятие программистов. Все мы хотим контролировать процесс разработки на всех уровнях: это оставляет много места для подвигов и личного героизма.
Но наступает момент — и написание блога в совокупности с десятком статичных страниц (flatpages, если по-джанговски) начинает казаться чем-то лишним. В свой светлый миг я решил исследовать мир на предмет CMS, основанных на Django.
Оказалось, что выбор здесь следующий:
- легковесные системы на базе flatpages
- несколько неприглядный PyLucid
- гибкий feincms
- DjangoCMS с его приятным сайтом и внятной документацией
Из коробки наибольший функционал предоставлял DjangoCMS, именно поэтому первый
промышленный опыт решено было получать на нем.
Установка
Последнее веяние питоновской моды (если не необходимость) — использование среды virtualenv. Это "песочница", в которую устанавливаются все зависимости будущего проекта: сам интерпретатор, стандартный инструментарий, необходимые библиотеки. В нашем случае — Django и DjangoCMS.
Создадим директорию cms-project, в ней — среду virtualenv:
# все то, без чего на Питоне нормальные люди не пишут: sudo apt-get install python-setuptools python-dev build-essential python-pip python-virtualenv # проходит некоторое время... # готовим уголок проекта: mkdir cms-project cd cms-project # создаем окружение в дир-рии env, ключ --no-site-packages закрывает доступ # окружению к глобальным библиотекам системы virtualenv --no-site-packages env
Теперь ставим django, DjangoCMS и PIL (Python Imaging LIbrary), находясь прямо в
той же дир-ии (cms-project):
pip install django -E env/ # ... pip install django-cms -E env/ # ... pip install pil -E env/ # ...
Кстати, используется pip, который немного лучше обычного easy_install. Ключ -E и его аргумент указывают на директорию окружения, в которую раскладывается пакет. Теперь запустим окружение (по-прежнему находясь в cms-project):
. env/bin/activate
Теперь находимся в окружении (env), нам доступны команды Django, установленного в окружение:
django-admin.py startproject tstproj
Корректируем, как обычно в Джанго, tstproj/settings.py (БД и прочие мелкие
радости). Подключаем админку, не забываем сделать в директории MEDIA_ROOT
симлинк на ее статику.
Проверяем работу фреймворка:
cd tstproj python manage.py runserver
Теперь надо подключить django-cms. В общем-то, это просто. Надо лишь добавить процессоры контекста, само приложение, создать хотя бы один шаблон. Опять же, в MEDIA_ROOT — симлинк на статику cms, в settings.py — переменная с адресом cms. Создание симлинка в моем случае (вся статика — в директории tstproj/media/)
выглядит так:
cd tstproj/media/ ln -s ../../env/cms/media/cms/
Вуаля. Пробуем:
cd tstproj python manage.py runserver
Заходим браузером в админку(по умолчанию http://localhost:8000/admin/), и — о, счастье! — попадаем в CMS.
Маленькие радости CMS
Итак, что дает нам CMS.
В интерфейсе администратора появляется пункт "CMS" с подпунктом "Pages". Здесь
располагается сердце приложения — карта-дерево сайта. Можно подлючать страницы,
управлять их публикацией и включением в меню.
Создание каждой страницы начинается с указания шаблона. Шаблоны перечисляются в
переменной CMS_TEMPLATES в файле settings.py.
Шаблон — обычный для Джанго, со включенными тегами cms_tags. Главный тег — placeholder, указывающий места включения плагинов. Другие удобные теги — show_menu и breadcrumbs, позволяют включать в шаблон навигационное меню и "хлебные крошки". Внешний вид вспомогательных элементов легко регулируется в отдельных шаблонах.
Места, отмеченные тегом placeholder, из интерфейса администратора можно будет заполнить плагинами. Из коробки доступны плагины включения в страницу форматированного текста, ссылок, файлов, картинок, Google Map, кусков html.
Новые плагины создаются очень легко на базе имеющихся моделей, интерфейс управления содержимым плагина можно генерировать автоматически — как с обычными моделями Django.
Для человека, знакомого с разработкой на фреймворке очень удобно, что в карту сайта можно добавлять обычные приложения Джанго — и навигационное меню будет их учитывать. Приложения для этого надо зарегистрировать в settings.py:
CMS_APPLICATIONS_URLS = ( ('mysite.app.urls', 'Some app'), )
Приложения также могут модифицировать поведение навигационного меню. Например, перечислять элементы каталога, разделы магазина и так далее.
Вот и все. Впрочем, большего лично мне и не надо.
А вот так, собственно, выглядит карта сайта:
![](http://www.django-cms.org/media/uploads/cms_page_media/2/3_pagelist___.png)
Волшебный WYSIWYG:
![](http://www.django-cms.org/media/uploads/cms_page_media/2/5_plugindetail___.png)
Редактирование страницы сайта:
![](http://www.django-cms.org/media/uploads/cms_page_media/2/4_pagedetail___.png)
Вывод
Интерфейс администратора достаточно прост и его не стыдно показать заказчику сайта.
Плагинов и расширений пока немного, но веб-программисту не составит труда подключить любое из обычных приложений Django либо разработать новый компонент.
Нужно отметить внятную и удобную документацию.
В общем, DjangoCMS2.0 вполне подходит для людей, часто имеющих дело с Django и привыкшими к удобной разработке на Python.
UPD: Найти документацию по проекту, скачать пакет, найти плагины или расширения можно здесь
UPD2: Картиночки влепил с официального сайта по просьбам трудяг-программистов. Проверял лично — все так и выглядит.