DjangoCMS2.0 — быстрее, больше, эффективней

    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 стоит); история богаче. Поэтому лично я выбрал Питон (и, соответственно, Джанго) в качестве сначала вспомогательного скриптового языка, а затем, когда открылись все богатые его возможности, и основного.

    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'),
    )
    


    Приложения также могут модифицировать поведение навигационного меню. Например, перечислять элементы каталога, разделы магазина и так далее.

    Вот и все. Впрочем, большего лично мне и не надо.

    А вот так, собственно, выглядит карта сайта:



    Волшебный WYSIWYG:



    Редактирование страницы сайта:



    Вывод



    Интерфейс администратора достаточно прост и его не стыдно показать заказчику сайта.

    Плагинов и расширений пока немного, но веб-программисту не составит труда подключить любое из обычных приложений Django либо разработать новый компонент.

    Нужно отметить внятную и удобную документацию.

    В общем, DjangoCMS2.0 вполне подходит для людей, часто имеющих дело с Django и привыкшими к удобной разработке на Python.

    UPD: Найти документацию по проекту, скачать пакет, найти плагины или расширения можно здесь

    UPD2: Картиночки влепил с официального сайта по просьбам трудяг-программистов. Проверял лично — все так и выглядит.
    Поделиться публикацией
    Похожие публикации
    Ой, у вас баннер убежал!

    Ну. И что?
    Реклама
    Комментарии 163
    • 0
      Довольно интересно.
      Надоело писать свой django-велосипед под простейший сайт. А использовать решения на PHP типа Drupal — уже не хочется.
      Качаю, буду пробовать.
      • –2
        Надо будет попробывать.
        • 0
          Спасибо. Недавно увлёкся Jango, будет интересно посмотреть на этого зверя)
        • 0
          А есть какие-то инструменты чтобы это на венде потестить?
          • 0
            Ну… Думаю, и Апач, и Питон, Джанго можно запросто поставить на Винду.

            Другое дело, что лично я никогда этого не делал :)
            • +5
              а нафиг апач?
              python manage.py runserver
              Есть некоторые траблы под виндой с MySQL — Python библиотекой но вполне решабельны.
              • 0
                Тьфу. Туплю. Я про раскладывание всего комплекта подумал почему-то.
                • +1
                  А зачем mysql? slite3 из коробки идет. На поиграться вполне хватит.
                  • +1
                    можно. но достаточно грустно все будет. Хотя на поиграться точно должно хватить.
                • 0
                  На мой взгляд путь гостевой оз в виде линукса или BSD намного проще (не смотря на первичную монструозность))))
                • 0
                  Достаточно поставить сам Питон (скачать/устанвить), БД (см. список поддерживаемых) и питоновский коннектор к данной БД (для MySQL нужны небольшие танцы, например).
                  • 0
                    а что у вас за танцы были-то? никогда проблем не было
                  • 0
                    Позавчера ставил Python 2.6 + python-mysql для него. Никаких проблем.
                    • 0
                      Под Win32?
                      • 0
                        Windows 7
                        • 0
                          В общем еще полгода назад была следующая проблема: основной мэйнтейнер коннектора сказал, что у него винды нет и винду он поддерживать не будет (ибо не может). Поэтому коннектор под Python 2.6 приходилось собирать самому. Под никами это обычно не проблема, а вод под виндой… :(
                          • 0
                            Да, было такое. Но это не мешало мне пользоваться 2.5.2 )
                            У 2.6 больших преимуществ не вижу.

                            Думаю вернуться на кодинг под MacOS, т.к. реально анноящая вещь — это utf-8 и win
                  • +1
                    bitnami.org/stack/djangostack
                    На здоровье!
                    • 0
                      Как-то неодолюбливаю подобные вещи.
                      Если сам ставишь — то знаешь какая версия стоит и что от нее ожидать.
                      Но это сугубо мое имхо.
                    • 0
                      Если хочется локального web сервера не заморачиваясь, то я пользуюсь иногда DENWER — Джентльменский Набор Web-Разработчика

                      Базовый пакет:
                      — Apache2 + SSL
                      — PHP5
                      — MySQL5
                      — phpMyAdmin

                      Может работать с флешки.
                      • +1
                        Пакеты расширений:
                        * PHP 5: дополнительные модули
                        * PostgreSQL 8.2 + модули PHP
                        * Денвер + Parser в одном пакете
                        * PHP 4: полный дистрибутив
                        * ActivePerl 5.8
                        * ActivePython 2.5
                        * Parser 3 с поддержкой XML, SQL и эмулятором SMTP-сервера
                        * Apache 2.2: дополнительные модули
                        * PHP 3: полный дистрибутив
                        * FireBird 2 + модули PHP
                        * MySQL 5: дополнительные модули и утилиты
                        * MySQL 4: предыдущая версия
                    • 0
                      Хотябы пару скриншотиков самых интересных мест цмски бы дали.
                      Они там есть, я уверен :)

                      Если серьезно то DjangoCMS вещь стоящая, сами юзали. Были некоторые проблемки но совсем незначительные, по моему с обновлением моделей при обнослении версии, а так летает замечательно.
                      • +1
                        А вас не смущает такое изобилие запросов к БД?

                        А так я рад что DjangoCMS засветился на хабре, давно за ним слежу…
                        • 0
                          всмысле в самой CMS? Да не очень в принципе.
                          До этого стояло что то PHPшное, кажется симфони — там было побольше, на порядок.
                          • +1
                            сам django-cms не использовал, но один раз помогал отладить сайт на ней. Выдавала она огромную кучу запросов на страницу. Для каждой i18n-строчки текста делалось около 50 запросов — по числу локалей в джанге. Быстрое ковыряние исходников показало, что причина — настройки LANGUAGE_CODE и LANGUAGES в settings.py, а точнее — их отсутствие. После добавления этих настроек все стало более-менее ок. Баг репорт не оформлял, может это фича такая, а может в версии 2.0 ее уже и нет, но если что, имейте в виду.
                          • 0
                            все для народа ;) Любуемся!
                          • НЛО прилетело и опубликовало эту надпись здесь
                            • +1
                              О-хо-хо… А что вас интересует? :-D
                              • НЛО прилетело и опубликовало эту надпись здесь
                                • +2
                                  Что значит «забежал»? :) Я в этом блоге живу практически! :)

                                  Отступы… Отступы… А надо нормальный редактор использовать, и не будет проблем с отступами :-P
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • +3
                                      Автор — я, если вы не обратили внимание, можно лично вопрос задавать.

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

                                      С — почти ассемблер
                                      C++ — это типа Си плюс сверху объектность и чудная STL.
                                      Java — аккуратный C++ со сборщиком мусора, беспроблемной кроссплатформенностью и без сишных архаизмов
                                      Perl — жуткий синтаксис, но зато regex и oneliners

                                      Но ПэХэПэ… Ух. Вроде как шаблонизатор встроенный, да. Но вроде как сейчас это уже не актуально, в эпоху-то mvc и отделения логики от представления. А что остается? уродский синтаксис да слеши в импорте модулей?
                                      • 0
                                        А если по существу?
                                        Вы смотрели нормальные PHP фреймворки, а не убогие CMS?
                                        • +1
                                          Что есть «нормальные PHP фреймворки»? CodeIgniter и Symfony подойдут?
                                          • +8
                                            Так это и есть «существо».

                                            Веб-фреймворки красивые сейчас есть у всех: у Руби, у Питона, на Php (да, я смотрел CodeIgniter, Zend и CakePhp). В этом смысле — все равно, они общую модель используют. Тут дело именно в языке, его выразительности, комфортности, удобоваримости.

                                            Кроме того, выучил Питон — пишешь что угодно. Веб (с Django, Turbogears или еще чем-нить), игрушки (pygame и родственники), сетевые приложения (смотреть и радоваться Twisted), скриптование приложений (типа 3d-рисовалок blender или houdini), собирать С/C++ проекты (scons), писать интерфейсы (PyQt, PyGTK, WxWidgets). В общем, ВСЕ.

                                            И везде преследуют удобство, легкость и простота.

                                            Пусть бросит в меня камень тот, кто все это получит в php!
                                            • НЛО прилетело и опубликовало эту надпись здесь
                                              • +5
                                                Да сложно сказать.

                                                Руби — типа двоюродный брат Питона, но с более развитой системой метапрограммирования и не такой строгой процедурой принятия фишек в ядро языка.

                                                Я в свое время выбрал все же питон, потому как у него:

                                                1) библиотек больше, они старше;
                                                2) стабильный синтаксис;
                                                3) очень жестко отбираются фишки под включение в язык;
                                                4) в те времена интерпретатор Руби был в полтора раза медленней;
                                                5) интерпретатор по умолчанию включен в поставку среднего линукса;
                                                5) мне не нравится писать endif в конце блока :)
                                                • +1
                                                  Всетаки понятие «красоты синтаксиса языка программирования» — очень субъективная вещь =)
                                                  Прочитал ваш переченеь склонивших в сторону выбора Питона причин и попытался востановить аналогичный для Руби, когда сделал выбор в его сторону в аналогичной ситуации. Сейчас понимаю, что решающими были всего две:

                                                  1) Нестабильный синтаксис (по аналогии с вашим вторым пунктом, то есть нет столь жесткого навязывания форматирования кода на уровне самого языка и возможность довольно легкого переопределения даже базовых операторов).
                                                  2) При работе со сроками, как с индексированым массивом, возможно его прямая модификация (если есть text=«Тексты», то в Руби жизнеспособно text[-1]=«у» и значение text станет «Тексту», а в Питоне нет).

                                                  Сейчас использую с определенной периодичностью оба языка (решаюшим оказывается наличие готовых решений на том, или другом позволяющее наиболее быстро решить поставленную задачу). И понимаю наивность вышеобозначенных выводов =) Особенно с учетом того, что программирование для меня не является моим прямым профелем (я арт-директор), скорее определенный уровень знаний на этой ниве — следствие стремления не делать обезъяньей работы (первым был скриптик пакетной обаработки изображений, потом скрипты для гимпа и блендера, а дальше больше). Но при прочих равных все равно выбираю Руби. Наверное потому что первый (освоенный по собственному желанию, а не как Cи++, Pascal, Basic в ходе обучения в школьные и студенческие годы «из под палки»)…

                                                  «Кстати, на твой вкус — руби или питон?» — у меня лично вызывает улыбку, даже не над самим вопросом, а скорее от настольгии котую он у меня вызывает. И отвечаю обычно: «тот который нравится».
                                                  • 0
                                                    Еще больше улыбает то, что вопрос был задан человеку, пишущему в блоги Python/Django :)

                                                    Однако, согласитесь, Питон из-за своей предсказуемости на уровне интуиции воспринимается существенно легче; незнакомые решения и либы читаются быстрее даже человеком, слабо знакомым с языком.

                                                    Примеры же усложения из мира Руби, думаю, назвать сможете вы и без моих подсказок.
                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                      • 0
                                                        Я бы советовал все же начать с Питона, если у вас нет большого профессионального опыта программирования на каком либо другом языке. Причина проста — Питон более строг, он «воспитывает» программиста, приучая его к принципам необходимым любому проффессионалу в этой области. И если вы дорастете до такого уровня, что «воспитание» будет вам мешать, вы с легкостью перейдете на «очень вольный» Руби, причем эта его «вольность» станет для вас преимуществом, а не как в любом другом случае недостатком. Причем перход фактически будет обусловлен изучением даже не самого языка а ифроструктуры вокруг него (фреймворки, библиотеки, готовые решения и прочее). По близкой мне аналогии, любой школьник от скуки закрашивал хоть раз на уроке клеточки ручкой, но Малевич посвятив пол жизни изучения классичекой хубожественной школе и уже после перейдя к привитивизму и кубизму написал «Черный квадрат», будоражущий до сих пор умы современников, не подходом и техникой, а самой идеей.
                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                      • 0
                                                        Соглашусь, более того, много проще воспринимается не только малознакомым с языком, но и не знакомым вообще с Питоном вообще, а лишь с поверхностно с каким то другим и с английским языком. Но эта его жесткая диктующая позиция, являющаяся безусловным плюсом в большинстве случаев является большим ограничением, когда речь идет о нетривиальном проекте, котороый решает уже состоявшийся программист высокого уровня (он уже знает как грамотно оптимизировать код, как его лучшим образом форматировать, причем в каждом отдельном случае а не «в общем» и навязывание лишь препятсвует его работе). И вот именно в этой нише отличительная черта Руби и проявляется как достоинство, а не недостаток. И именно поэтому я с различной периодичность «прыгаю» с одного языка на другой, именно исходя из задачи, а не личных предпочтений — такой подход, по крайней мере для меня, оказался боле продуктивным. А для задач математики, аналитики или преобразования и форматирования текста вообще все больше использую Javascript так как интерпритатор есть повсеместно и не требует инсталяции, а концепция языка, хоть изначально и не скажешь более всего близка к Perl, и в какой то степени его последователю Ruby.
                                                        • 0
                                                          А уверены, что в вашем нетривиальном случае надо использовать всякие хитрые ужимки? Не будет ли это «подарочком» для программиста, который придет после вас?

                                                          Обратите внимание на корпоративные руководства или официальные стили кода.

                                                          Правило номер 1: не выдумывайте, не извращайтесь, не запутывайте код.

                                                          Текст программы должен быть предсказуем. Функции остаются функциями, обычные операторы — операторами, классы — классами, а цыпленок — цыпленком.

                                                          На примере C++ могу указать на фишки в стиле Александреску, которые чаще просто запрещено использовать.

                                                          Код моих знакомых высококлассных программистов отличается не уникальными решениями, а:

                                                          1) читаемостью,
                                                          2) лаконичностью,
                                                          3) простотой,
                                                          4) архитектурной стройностью.
                                                          • 0
                                                            О том я и гвоорю =) Профессионал, тот кто точно знает меру своей осведомленности и работает только в ее рамках. Это в первую очередь подразумевает большой практический опыт. Перечисленные качества кода ваших знакомых это следствия, к которому они пришли «набив шишки» при получении этого опыта. Они уже без указок со стороны знают, как сделать решение более читаемым, лаконичным, простым и маштабируемым. Причем в каждом конкретном, отдельно взятом, случае, а не в общем. Они не будут тупо следовать шаблонам, и не станут разбивать на блоки, то что более понятно будучи записаным в одну строку, так как они уже знают где упрощение, а где недосказанность. Они, при необходимости, для какой либо предметной области создадут и используют DSL, сводящая фактически код программы к записи на английском языке или матиматической нотации, понятной даже не программисту. Их опыт это в первую очередь знание и умение использовать себе на пользу специфики.
                                                            Жесткая регламентация способствует конвееру, благодаря тому что таковая заложена в концепцию Питона, результат работы средних и даже откровенно слабых специалистов приносит максимальную эффективность для этого конвеера. Поэтому высококлассные специалисты в первую очередь, работая в рамках конвеера, придерживаются регламента и всячески его пропогандируют.
                                                            Рабочий собирающий фары не должен знать куда они будут ставится и даже не обязан понимать принцип их работы, но инженер разрабатывающий автомобиль долже знать, и не только это, но и многое другое. У любого правила есть исключения, это аксиома. Строгое следование правилу дает большую отдачу, но не работает в исключительных ситуациях в принципе. Вот Руби как раз и позволяет доробатывать эти исключения, за счет того, что следование общему правилу остается на совести разработчика, а следовать он ему будет лишь будучи профессионалом. По этой причине, на мой взгляд, Руби как и Перл будет оставаться нишевым продуктом. Для эксперементов и программирования возведенного в рамки исскуства. В массовое производство ему дорога закрыта, только для интузиастов и более удобной реализации творческой составляющей профессионалов. Однако это не относится к продуктам на его основе, как пример Рельсы, в полне себе конвеер, знания языка для его использования минимальны. Потому и так популярен, да настолько, что ранее многие начинающие вообще считали, что Руби и Рельсы синонимы.

                                                            Как то так. Немного в философию ударился, есть грешок. Но думаю мысль ясна =)
                                                            • 0
                                                              Perl — нифига не нишевой продукт. Когда-то он был Главный Динамическим Языком, на котором делалось все: от однострочных скриптов до порталов.

                                                              Однако, синтаксические недостатки, сложность в освоении и поддерке сделали свое дело. И вот теперь он стал нишевым продуктом.

                                                              Подозреваю, что весь это hype вокруг RoR тоже сойдет на нет. И вот только после этого можно будет рассуждать, оказались ли специальные возможности языка излишеством или преимуществом.
                                                              • 0
                                                                Перл — нишевый продукт, но когда-то все было с точностью до наоборот.
                                                                Судьба Рельс и Руби уже сейчас идут паралельно, за исключением того что интерес к первому порождает большой приток людей интересующихся вторым.

                                                                У меня складывается стойкое впечатление, что я говорю сам с собой. Не втом смысле, что я не понят, а в том что схожий взгляд на вещи и ход рассуждений. =)
                                                • +1
                                                  В том то и дело, мб я один так считаю и Вы правы, но я считаю каждый должен заниматься своим, Py очень уважаю, но из-за идеологии чтоли не хочу тянуть их в Web, по мне так каждый должен заниматься своим, а PHP именно Web.

                                                  Про удобство кода — повторюсь, это дело привычки и опыта, если человек прекрасно пишет на PHP много лет и трудностей не испытывает — смысл ему из-за удобства переходить на другой язык?
                                                  • +4
                                                    Это ведь тоже только мое мнение :)

                                                    Но я могу его обосновать.

                                                    Специализация — понятие относительное. Все идет к универсальности. Программистам не нравится изучать новый язык под каждую задачу. Именно поэтому Руби так силен своими Domain Specific Languages.

                                                    Опять же, специализация в этом случае ничего не дает, а только ограничивает. Повторюсь, и опять напишу, что фреймворки есть везде. Хорошие, плохие… На Перле, на Хаскелле, на Руби, на Питоне… Абсолютно везде они есть, и в этом смысле нет разницы, на чем писать.

                                                    Но какой-то язык прост, изящен и располагает к написанию понятного, чистого кода. Какой-то — обладает специфичными неинтуитивными особенностями, которые надо специально изучать.

                                                    Например, Перл. Правда, там ужасный синтаксис. Но зато в одну строчку можно сделать очень много.

                                                    В Php нет ничего нового или особенного, только некрасивый, избыточный синтаксис. При всех прочих равных условиях язык проигрывает.

                                                    Именно поэтому даже люди, много лет пишущие на php, часто поглядывают в сторону знаменитой изящности Питона или DSL в Ruby.
                                                    • +1
                                                      Убедили =( Как не прискорбно осознавать =(
                                                      Будем пробовать. Пока студент. Пока время есть…
                                                      • –1
                                                        > В Php нет ничего нового или особенного, только некрасивый, избыточный синтаксис.
                                                        Обычно так ворчат люди, которые писали на PHP3(ну или те, которые используют PHP5, но пишут также как писали бы на PHP3):-)
                                                        Вообще Python много больше умеет по сравнению с PHP(например, множественное наследование, которого у PHP еще долго не будет), однако Python гораздо старше PHP. «Нормальная»(думаю вы поняли почему в кавычках:-)) ООП версия — PHP5 вышла примерно в 2004-2005 ), а Python в 1991 уже позиционировался, как ООП язык программирования. Поэтому логично, что разработчики «на» PHP смотрят в сторону более «умных» языков, но насчет синтаксиса, оформления кода — здесь на мой взгляд у Pythona дела обстоят гораздо хуже. Сравните, например, спецификаторы доступа: в Python это подчеркивания, а в PHP — ключевые слова. Какой код по вашему будет читать лучше? По моему мнению, гораздо лучше читать слова, а не считать подчеркивания.
                                                        Все… навеяло… пойду писать статью о сравнении синтаксиса PHP и Python :-)
                                                        • +2
                                                          Вы смеетесь? Это я про спецификаторы доступа. Это вообще просто «джентельменское соглашение».

                                                          1) Питона в 91 году не было;

                                                          2) Питон с самого начала провозгласил своим кредо простоту и изящность;

                                                          3) уже к середине 90х он обрел современные очертания.

                                                          Так если php моложе, то он должен быть более современным. Так почему же получается, что он отстает?
                                                          • +2
                                                            оп-па… Питон уже был. Пардон — деза.
                                                            • 0
                                                              Python изначально разрабатывался, как универсальный язык программирования, и поэтому у него значительно больше преимуществ. В отличие от PHP, который был разработан с целью «учета посетителей», однако именно это он делает лучше всех:-) А из-за простоты и понятности многим людям, в отличие от Python, в котором надо еще и философию знать:-), на PHP пересели множество быдлокодеров и из-за этого язык PHP ассоциируется у многих с отставанием мозга в развитии :-)

                                                              Что касается подчеркиваний, я почему-то очень верю, что вы, как и многие другие, используете это «джентельменское соглашение»:-) Вот, кстати еще один пример, исключения у нас бросают(кидают) и ловят как PHP(throw и catch), а не поднимают и исключают как в Python(raise и except). Конечно у Python с обработкой исключений лучше, чем у PHP, но код наглядней на PHP.
                                                              • 0
                                                                Я прекрасно знаю историю Php :) Знакомство мое с ним началось лет восемь назад.

                                                                Тут не в этом же дело. Говорить «он такой, потому что изначально предназначался для другого» — значит закрывать глаза не его откровенные минусы. А люди, может, ничего закрывать не хотят в принципе :)
                                                          • 0
                                                            У ПХП есть одна особенность, выделяющая его на фоне других. Это повсеместная распростаненность на хостингах. Питон и Руби в этом отношении, в данный момент, в данной нише в роли догоняющих.
                                                            • 0
                                                              Ну это да.

                                                              Хотя, в общем-то, проблема уже не стоит. Скажем так, php есть на каждом хостинге, Python — часто встречается.
                                                          • +4
                                                            По своему опыту скажу — стоит. Мне было удобно на php, трудностей не испытывал, потом решил попробовать питон (спасибо кризису за свободное временя) — и с тех пор считаю те 4 года, что уделил php, практически бесполезной тратой времени. Как, кстати, и 4х-летнее усиленное разбирательство с тонкостями C++. Даже немного жалко потраченного на это все времени, ввиду крайне малой области разумного применения C++ и того, что (на мой нынешний вкус) php проигрывает python'у абсолютно во всем (синтаксис, библиотеки, коммьюнити, фреймворки, документация), ну нет у php преимуществ кроме сомнительного mod_php, который позволяет запустить все новичку почти без настройки (угу, а потом писать статьи о глобальной проблеме веб-разработки — ИНКЛУДЫ тормозят — а какого черта каждый раз при каждом запросе все вообще инклудится-то и с диска читается?).

                                                            Кроме того, может, это какая-то моя личная особенность, но, как сейчас вижу, меня разработка на php сначала приучала к каким-то корявым велосипедам. Потом наступала реакция в виде архитектурной астронавтики, как попытка от этой корявости уйти. Что, в итоге, было ничем не лучше. И причем, что самое неприятное, я был вполне доволен собой (и считал себя отличным программистом), когда писал отстойнейший код, который было невозможно поддерживать.
                                                            • 0
                                                              > когда писал отстойнейший код, который было невозможно поддерживать.

                                                              Вы действительно считаете, что в этом виноват PHP? :-)
                                                              • +1
                                                                «может, это какая-то моя личная особенность»
                                                              • 0
                                                                php проигрывает python'у абсолютно во всем (синтаксис, библиотеки, коммьюнити, фреймворки, документация), ну нет у php преимуществ кроме сомнительного mod_php,

                                                                Хотя эти вещи напрямую не относятся к преимуществу языка и технологии, но утверждение спорное насчёт коммьюнити и документация.

                                                                Если документация, имеется ввиду, официальная, то тут ничего не могу сказать, но если считать количество литературы и статей по PHP, относительно статей и книг по веб-разработке на PYTHON, то PHP тут, наверняка, в выигрыше.

                                                                Тоже самое и насчёт коммьюнити.

                                                                Я думаю, что «попсовость» PHP, а следовательно и наличие большего количества литературы и обширного коммьюнити — это то, что заставляет многих начинающих, и не только, веб-программистов закрыть глаза на некоторые недостатки PHP в плане синтаксиса, ооп итд итп

                                                                • +1
                                                                  Количество книг и статей вовсе не говорит об их качестве.
                                                                  • +7
                                                                    Хотя эти вещи напрямую не относятся к преимуществу языка и технологии, но утверждение спорное насчёт коммьюнити и документация.


                                                                    Скажем, субъективное. Коммьюнити и документация лучше «на мой вкус». Дальше объясню, почему на мой вкус это так.

                                                                    Если документация, имеется ввиду, официальная, то тут ничего не могу сказать, но если считать количество литературы и статей по PHP, относительно статей и книг по веб-разработке на PYTHON, то PHP тут, наверняка, в выигрыше.

                                                                    Тоже самое и насчёт коммьюнити.

                                                                    Я думаю, что «попсовость» PHP, а следовательно и наличие большего количества литературы и обширного коммьюнити — это то, что заставляет многих начинающих, и не только, веб-программистов закрыть глаза на некоторые недостатки PHP в плане синтаксиса, ооп итд итп


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

                                                                    А с php ситуация какая (по крайней мере, была, когда я им занимался) — книг и статей много, а умных и хороших мало. Очень много информации от новичков для новичков. И среди все это приходится продираться, чтоб отыскать действительно полезную информацию. Одни названия некоторых книг чего стоят (http://www.bhv.ru/books/book.php?id=326).

                                                                    О коммьюнити и документации я говорю с точки зрения более-менее опытного программиста, который решил перейти в веб, а не с точки зрения новичка, который только начинает программировать. Для второго, наверное, php будет проще, информации по нему больше. А для первого проще и понятнее должен оказаться питон — прочитал какой-нибудь dive into python и в путь.

                                                                    Насчет коммьюнити — мне в питоне нравится, что там люди часто действительно грамотные, и нет такого большого количества самоуверенных новичков, дающих глупые советы, как в случае с php. Если, например, непонятно что-то в документации к logging — можно написать в python-users, и есть неплохая вероятность, что тебе грамотно ответит именно тот человек, что писал этот модуль 7 лет назад.

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

                                                                    Но, вообще, это все не в ту степь. В коммьюнити главное вовсе не ответы на вопросы, главное в коммьюнити — это библиотеки. И вот тут коммьюнити php значительно проигрывает коммьюнити python'а. Большинство ведет наколеночные разработки велосипедов, коммуникации затруднены, качество кода часто плохое, разработками принято делиться в формате — вот написал что-то, скачайте архив. Так и живут. Идем, например, на github. Запрос по языку «php» выдаст 9513 репозитория. Запрос по языку «Python» — 15532. И это при том, что абсолютный размер коммьюнити у питона в разы меньше.

                                                                    А вот почему так просиходит — думаю, из-за того, что в чужом коде на питоне разбираться значительно приятнее, чем на php.

                                                                    Как пример — в php-фреймфорке symfony сделали отличный debug toolbar. Один джангонавт это увидел и подумал: «О, отличная идея!» Появился репозитрий на github. Сейчас за ним следит пол-тыщи человек, многие шлют патчи и улучшения, кто-то сделал офигенный дизайн, и сейчас джанговский тулбар уже ничуть не уступает, а, скорее всего, и значительно превосходит тот, что есть в symfony.
                                                              • НЛО прилетело и опубликовало эту надпись здесь
                                                                • НЛО прилетело и опубликовало эту надпись здесь
                                                                  • +1
                                                                    Это будет завтра. Времена меняются. Если Гвидо будет продолжать в том же духе — то лет пять-десять безболезненного существования нам вполне обеспечено.

                                                                    А сегодня… php-скриптом можно сыграть, конечно, и сайт, и портал, и все такое. Но даже если закрыть глаза на синтаксис, то останется море задач, которые он решать не умеет.

                                                                    Система сборки проекта? Игрушечки? Системное скриптование? Апплеты для Гнома, КДЕ? Интерфейсы на Qt?

                                                                    Зачем один посредственный язык для веба и один хороший — для всего остального? Лучше свести все к общему знаменателю и не париться.
                                                                    • НЛО прилетело и опубликовало эту надпись здесь
                                                            • НЛО прилетело и опубликовало эту надпись здесь
                                                            • +3
                                                              Сразу оговорюсь — я достаточно много писал на PHP; много работал на Java.
                                                              За что влюбляешься в Питон — это за то, что там есть очень много приятных и казалось бы незначительных мелочей, которые вместе очень сильно упрощают и разработку и поддержку кода.

                                                              Из того, что важно для меня: 95% всякого однотипного мусора в коде можно нормально выносить за счет всяких декораторов и использования функционального программирования; очень грамотно организована работа с коллекциями и различными композитными типами; на Питоне действительно можно писать компактный легкочитаемый код.

                                                              Всего после пары недель общения с Питоном (вкупе с Джангой) у меня полностью пропало желание писать еще хоть что-нибудь на PHP :)
                                                              • 0
                                                                Автор помоему имел ввиду другое, что PHP уступает во многом аналогам по функциональности.
                                                                Про удобство — это дело каждого. ИМХО конечно.
                                                                • 0
                                                                  Уступает. Например на PHP несколько затруднительно сделать что-нибудь вроде индикатора прогресса загрузки файла на сервер. Во всяком случае все реализации которые я встречал — использовали что-нибудь левое.
                                                                  • –3
                                                                    Левое это JS?
                                                                    • +2
                                                                      Нет, JS-тут не помог бы :)

                                                                      Для контроля процесса получения файла я встречал либо небольшие Perl-скрипты на стороне сервера либо флеш на строне клиента.
                                                                      • 0
                                                                        Спать пора… JS и Flash попутал…

                                                                        Будем пробовать в свободное время, будем сравнивать =)

                                                                        Пока не считаю это критичным, Flash не люблю но все-таки серверная и клиентская части разные — поэтому не считаю это левым.
                                                                        • 0
                                                                          поискал побольше — какже не помог? а это: habrahabr.ru/blogs/jquery/75420/
                                                                          • 0
                                                                            Там jQuery опрашивает серверный скрипт для узнавания прогресса. С помощью непосредственно JS определить объем переданных данных нельзя. Что касается используемого здесь скрипта для определения прогресса, то в данном случае использована функция uploadprogress_get_info() из дополнительной либы.
                                                                            • 0
                                                                              Но Вы не писали что непосредственно чем-нибудь левым.
                                                                    • 0
                                                                      Я там чуть выше про функциональность, доступную из языка, написал.
                                                                  • 0
                                                                    У php довольно таки тяжелый и уродливый синтаксис, особенно когда речь идет об объектах — на Руби все пишется раза в 2 короче (хотите — верьте, хотите — проверьте). Плю в Руби лучше с элементами фукц. программирования, вроде замыканий. Плюс в Руби строки и массивы — объекты (ну это просто синтаксический сахар, но приятно ведь).
                                                                • 0
                                                                  Да? А они становятся? </сарказм> :)
                                                                • 0
                                                                  1) Быстрее ли (и меньше ли потребляют памяти) сайты на Руби и Питоне, тем более с использованием тяжеленных RoR/Django (и использованных там ActiveRecord), чем на php
                                                                  2) Меньше ли расходы на хостинг для Python/Ruby приложений.

                                                                  Я в общем-то по поводу синтаксиса спорить не буду — Руби в разы приятней php (а как там все плохо с замыканиями и динамически создаваемыми функциями — даже вспоминать неохота). Но глупо тратить силы, чтобы в результате получился тормозной сайт, которому еще и нужен отдельный VPS.
                                                                  • 0
                                                                    Я вас уверяю, на Джанго делаются тяжеленные сайты.

                                                                    Не нравится скорость ORM? Нафиг. Шаблонизатор? Нафиг.

                                                                    Хотя на самом деле даже это делать совсем не обязательно. Легко подключить memcached, управлять кэшированием запросов и отдельных видов. Ну и так далее, в светлое сверхзвуковое будущее :)

                                                                    Совсем уж дзен-буддисты, конечно, могут использовать микрофреймворки… Но это не моя история, мне времени жалко.

                                                                    • 0
                                                                      > Не нравится скорость ORM? Нафиг. Шаблонизатор? Нафиг.

                                                                      Может тогда и джанго выкинуть? И смысл тогда писать все на чистом Питоне? И зачем было включать в Django ORM и шаблонизатор, если они тормозят?

                                                                      А про «нагруженные» сайты — ну не надо этого, если поставить кучу VPS, так и Друпал летать будет (ubuntu.org кажется на Друпале ведь?). Только что-то ни твиттер, ни вконтакте тот же не используют никаких джанго.
                                                                      • 0
                                                                        Твиттер на Руби изначально делался, если что. множество очень крутых сервисов — на Джанго. У меня есть знакомая команда джангистов, которая именно на нагруженных сервисах специализируется.

                                                                        Помимо шаблонизатора и ORM в джанго еще ОЧЕНЬ много чего есть. Да и не так они плохи, чтобы просто так выбрасывать. Все равно понадобится аналог.

                                                                        Собственно, а что вы пытаетесь доказать? Что все вокруг с нуля на чистом php пишут? Или Java? Это просто-напросто неправда.

                                                                        Те же rambler, yandex используют тот же Джанго для своих проектов. У меня есть знакомый в sun, который пишет на Джанго. Ну и так далее.

                                                                        • 0
                                                                          Mail.ru тоже использует Django во внутренних проектах.
                                                                    • 0
                                                                      «ТЯжеленные» — читай «нагруженные»
                                                                • +2
                                                                  Мультиязычность в DjangoCMS2 очень хорошо реализовано, а в вашей статье о ней ни слова :)
                                                                  • 0
                                                                    PIL опасно так собирать. По крайней мере в Debian Lenny по умолчанию приведенным способом PIL будет собрана без поддержки jpeg. Чтоб PIL собралась с jpeg, следует кроме python-dev указать еще libjpeg-dev (и, может быть, zlib1g-dev, тут не запамятовал, может она для какого-то другого пакета нужна, но не помешает).
                                                                    • 0
                                                                      Хм. У меня Ubuntu, не проверял на jpeg. Думаете, отдельно и руками собрать в virtualenv?
                                                                      • 0
                                                                        «pip install pil» и так все собирает, в этом и затык
                                                                        • 0
                                                                          Если неправильно понял — прошу простить.

                                                                          Имеется в виду вот что — есть 2 варианта:

                                                                          1. Ставить PIL средствами apt (что-то вроде python-imaging, не помню, если честно)
                                                                          2. Ставить PIL средствами pip или easy_install. По большому счету — без разницы, в virtualenv или нет. Но чтоб PIL правильно встал этим методом, необходимы еще предварительно установленные через apt libjpeg-dev и zlib1g-dev.

                                                                          Поэтому в requirements PIL писать не следует, если нет контроля над тем, где будет идти установка, т.к. он может легко не собраться или собраться не правильно. А если контроль есть, то простой вариант — установить python-imaging через apt глобально. Или более сложный, если нужна последняя версия (или используется --no-site-packages) — устанавливать разные dev-пакеты.
                                                                          В любом случае, просто pip install PIL — опасно.
                                                                          • 0
                                                                            Я вот задумался. Получается, так легко «песочницу» с зависимостями не перетащить на произвольную машину? В любом случае как бы придется ставить глобальные либы?

                                                                            Иными словами, надо будет писать какой-то особый установочный скрипт?
                                                                            • +2
                                                                              Да, virtualenv+pip в общем случае недостаточно, даже если знаешь, на какую систему будет все ставиться.

                                                                              Кроме того, после установки песочницы нужно ж еще апач настроить, к примеру.

                                                                              Это все довольно просто автоматизируется с помощью fabric. Что-то вроде этого:

                                                                              def create_instance():
                                                                                  install_system_packages()
                                                                              
                                                                                  create_virtualenv()
                                                                                  create_clone()
                                                                                  setup_hg_hooks()
                                                                              
                                                                                  pip_install('basic')
                                                                                  pip_install('django')
                                                                                  pip_install('apps')
                                                                              
                                                                                  deploy_geoip()
                                                                                  create_wsgi_file()
                                                                                  setup_apache()
                                                                              


                                                                              это кусок из реального проекта, если что.
                                                                              • +2
                                                                                Ну а если речь идет про какое-нибудь, например, джанго-приложение, то сложные зависимости вроде PIL или mysqldb не помещают в requirements, а документируют.
                                                                      • 0
                                                                        Хорошая статья
                                                                        • 0
                                                                          а вот нельзяли по подробнее про virtualenv?
                                                                          сделал я его под проект, наколбасил дофига туда, понаставлял кучу вкусных модклей pipом,
                                                                          и что потом с этим делать?
                                                                          • 0
                                                                            import your_module

                                                                            вот и все. Суть там в том, что пути в окружении указывают на локальные пакеты в env, а не на системные.

                                                                            можно потом легко зависимости разработки отследить и повторить в другом месте: pip может сгенерировать файл requirements.txt.
                                                                            • 0
                                                                              тоесть какого-то логического завершения, типа сворачивания/разворачивания всего этого окружения нету?
                                                                              типа инсталяшку сделать чтоб на где-нибудь хостинге развернуть.
                                                                              • +1
                                                                                Можно. Конструктор соцсетей на джанге — pinax — так и работает.

                                                                                по файлу requirements.txt вытягивает нужные пакеты в место, где раскладывается пакет. Честно скажу, я не смотрел как именно это у них делается.

                                                                                Но можно; думаю, надо будет — справимся и я, и вы :)
                                                                                • 0
                                                                                  ну я то конкретно про virtualenv спрашивал
                                                                                  • 0
                                                                                    Ну а я конкретно по virtualenv и отвечаю. :)

                                                                                    Собственно, более-менее резонное использование virtualenv я увидел как раз в проекте pinax
                                                                                • 0
                                                                                  распространенный вариант:

                                                                                  virtualenv = изоляция проектов друг от друга
                                                                                  pip = автоматическая установка и обновление питоновских зависимостей
                                                                                  fabric = развертывание на сервере
                                                                            • 0
                                                                              Теперь надо подключить django-cms. В общем-то, это просто.

                                                                              В опере ссылка ведёт на www.xn--django-ms-13h.org/en/documentation/2.0/installation/
                                                                              Подозреваю, что в адресе www.django-cms.org буква «с» русская :)
                                                                              • 0
                                                                                У меня все правильно. Чего й то опера переписывает ссылку-то?
                                                                              • 0
                                                                                Поправка: в джанге не MVC, а MTV (Model Template View).
                                                                                • 0
                                                                                  Конечно, это не патриотично, но я все же подозреваю, что у их маблонов проектирования ОЧЕНЬ много общего :)
                                                                              • 0
                                                                                Хабралюди Питонисты, если вы объясните мне, как писать веб-приложения на python'e, чтобы не надо было, каждый раз после правок, перезапускать сервер (интерпретатор или как его?) — я обязуюсь вернуться к изучению этого красивого по синтаксису, языка! Уперся в это неудобство и лоб уже разбил. Или это не сильно неудобно!? :)
                                                                                • +3
                                                                                  Для разработки запускайте его в дебаго-моде:
                                                                                   $ ./manage.py runserver 

                                                                                  Этот режим специально сделал для разработки — джанга постоянно проверяет не изменились ли файлы, если да, тот тут же подкачивает. Еще один плюс: ошибки валятся в консоль. Плюс можно использовать любимый пхп-метод отладки — печать. Все ваши print-ы из функций тоже пойдут в консоль.
                                                                                  • 0
                                                                                    Если испольщуется WSGI
                                                                                    touch run.wsgi

                                                                                    но runserver конечно правильнее для разработки
                                                                                    • 0
                                                                                      хм. У меня в продакшне mod_python (да! Django! без прав рута! на модпитоне!). Сделал bzr push-and-update и все _сразу_ обновилось, без всяких перезапусков.
                                                                                    • 0
                                                                                      хочу попробовать питона=)
                                                                                      • +1
                                                                                        1. Перенесите, пожалуйста, статью в блог django
                                                                                        2. Если вы серьезно занимались расширением функционала django-cms, то может быть заметили проблему с диспетчеризацией url-ов при подклюении одного и того же приложения к нескольким страницам. Варианты решения были, поимо размножения urls[\d+].py?
                                                                                        • 0
                                                                                          Резоннно, перенес.

                                                                                          И нет, не сталкивался. Вы не могли бы поподробней? Что там происходит? ЧТо пишет? На что ругается? я прям сейчас пишу с ним жирный такой сайтик, надо бы знать о подводных камнях.
                                                                                          • 0
                                                                                            в общем, картина такая:
                                                                                            есть две страницы, к обеим прицеплено приложение блогов (blog). В блоге есть раздел архивов записей по годам/месяцам. Кусок urls.py для приложения выглядит как
                                                                                            url(r'^$', archive, name='archive-root')
                                                                                            , попытка указать в шаблоне страницы {% url archive-root %} приводит к тому, что каждый раз на обоих страницах урл генерится как бог на душу положит. То на одну страницу с приложением, то на другую. Есть задумка сделать отдельный тэг для этого. Покопавшись в нутрях самой djangocms я аналога не нашел, разве что mlurl, но он предназначен немного для других целей.
                                                                                            • 0
                                                                                              А-а-а-а… Ну так это не проблема DjangoCMS, это проблема ваших урлов.

                                                                                              Как, если по-вашему, диспетчер должен определять урл, если он просто дважды прописан? По идее, должен просто в порядке включения в коренной urls.py.

                                                                                              Мне казалось, что если по-разному назвать приложения в CMS_APPLICATION_URLS, то адреса должны быть разными. Или нет?
                                                                                              • 0
                                                                                                Частично да, но само приложение пишется в базе как <app_name>.urls — соответственно, можно не просто добавлять паттерны в пространство имен, а изменять url.name. Диспетчеризация так же проходит через контекст cms, поэтому и вижу возможным создание соотв. механизма. А разные названия приложению не помогут, если они будут ссылаться на один и тот же модуль.
                                                                                                • 0
                                                                                                  Да, тогда получается, надо писать в приложении отдельный урл под отдельную страницу с приложением. DRY нарушается.

                                                                                                  Тут надо тикет писать разработчикам DjangoCSM со своим патчем либо без него…
                                                                                        • +1
                                                                                          Интересно было бы увидеть сравнение по функция с Pinax. P.S. Я не знаю почему многие считают Pinax сац сетью это помоему просто CMS.
                                                                                          • +1
                                                                                            Я с Пинаксом полгода работал. Это просто большой комплект разных джанго-приложений. В рамках проекта разрабатываются всякие полезные штучки — ну и плюс просто хороший пример большой разработки.

                                                                                            Там нет дерева, не так легко и удобно страницы создавать и превращать в навигационное меню, нет вспомогательных CMS-штучек.

                                                                                            В общем, сравнивать их нельзя.
                                                                                            • 0
                                                                                              А как вам «социальный» функционал пинакса?
                                                                                              С чем бы сравнить… на грубо, говоря, на нем можно поднять аналог хабра, ливстрита еще чего-нибудь такого?
                                                                                              • 0
                                                                                                а почему нет? Блог надо будет, конечно, расширить под конкретные нужны, tribes и wiki убрать — и вперед. cloud27.com — неплохой авторский пример того, что можно сделать с Пинаксом.

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

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

                                                                                          Вот тут стоит удерживаться от лишних эмоций. Беспристрастность — язык мудрости.
                                                                                          Я понимаю Ваш энтузиазм, однако при всем моем уважении к Джанго, для «гораздо более зрелых» нужно все-таки дозреть еще на пару-тройку тысяч плагинов в библиотеке. Так что думаю, есть куда развиваться.

                                                                                          А в остальном, спасибо за интересный обзор :)
                                                                                          • +1
                                                                                            Это я не про DjangoCMS говорил, которая совсем свеженькая.

                                                                                            А про Zope и Plone. Это монстры, которые недооценены в России. Им много лет, тот же Zope уже давно перерос сам себя и собственные начальные цели.
                                                                                            • 0
                                                                                              Точно, это «монстры». Нет, нет так — это сущие «кошмары в ночи».
                                                                                              Я с ними работал год, это чудовищно, категорически не хочется возвращаться.
                                                                                              Впечателние после них такое: задумка очень мощная, интересная, но реализация — ужас!
                                                                                              На практике постоянно напарываешься на какие-то грабли.
                                                                                              • 0
                                                                                                В свое время они были очень, ОЧЕНЬ ничего. Да и никаких аналогов не было. Сейчас-то, конечно, резонней использовать решения на Django или Turbogears, одно из которых и предлагается в заметке.

                                                                                                А Zope… Zope как killer app отошел, да. Насколько понимаю, Zope3 — это уже не фреймворк, набор reusable элементов, которые встречаются много где. Скажем, в Twisted. Или один фирменный фремворк, на котором я работал с год.

                                                                                                Или Plone…

                                                                                                Да и настолько ли хорош какой-нибудь Drupal? Он уже подходит к состоянию Zope2, а скоро, пожалуй, и превзойдет его по сложности.
                                                                                                • 0
                                                                                                  только не надо писать «какой-нибудь Drupal» ;)
                                                                                                  На каком-нибудь друпе написан какой-нибудь там сайт Белого Дома. Не думаю, что сисы американской администрации настолько глупы что не разберутся что хорошо, а что плохо. У друпа совершенно свой путь и сообщество следит за тем чтобы он не стал монстром. И он не станет. Это не самая шустрая CMS, но он и не создавался для маленьких проектов.
                                                                                                  Неблагодарная это затея меряться CMS-ами, особенно без сформулированных критериев сравнения :)
                                                                                                  • 0
                                                                                                    «Какой-нибудь» — это в смысле «один из».

                                                                                                    А сайт ЦРУ — на каком-нибудь Plone сделан, который есть дитя Zope. :) Там и плагинов масса, и история, и бла-бла-бла. Как быть? :)

                                                                                                    Zope-то стал. И тчк. Хотя сообщество было ого-го. Или даже из-за того, что сообщество было «ого-го» :) Вон, я ядра линукса тоже сообщество, а строчек кода за 6 млн зашкаливает.

                                                                                                    В общем, я почему вспомнил и Plone, и Zope. Потому что с ними работают давно, так же как и с Drupal. Но так же как и Drupal, они стали сложными и тяжелыми.
                                                                                                  • 0
                                                                                                    В Зопе меня больше всего раздражала не сложность, а попытка вобрать в себя все, тот самый killer app. С идеологической стороны это грубое попрание UNIX-way (когда одно действие должна делать одна программа, а все остальное получается их комбинированием). А спрактической стороны получается, что этот комбайн все далает сам и делает фигово, а возможности заменить нет.
                                                                                                    Например, нужно разрабатывать какие-то скрипты, шаблоны и прочее — все это делается через веб-интерфейс — жутко неудобно. Ладно, с гемором я пробил переход на фтп. Ага, фтп-сервер в зопе свой. Просто так сделать файл нельзя (получается объект неправильного типа), значит опять надо идти в веб-морду, создавать там объект, после чего его можно заливать через фтп. А как насчет контроля версий? Какой-то реализован в самой зопе. Но это опять кошмар! Как надо он не работает, внешний svn не подключишь.
                                                                                                    А ZODB — это же беспросветнейший п… ц! Я могу ее годами матюкать, столько крови она у меня выпила! Это в полном соответствии с Кантом «вещь в себе». Работать нормально с ней можно только через веб-морду. Интегрироваться с ней извне — гемор. Мы делали крупный сайт, нам нужно было все увязывать с другими компонентами, чтобы данные поступали из КИС, текли на сайт и там отображались. Жуть! Лучшим решением оказалось избавиться от нее, хранить в ней только логику приложения и ходить за данными в нормальную реляционную базу. А что в итоге? Скрипты в неудобном для работы виде, данные в базе. Что там от зопы-то осталось? И ради чего это все тогда? Чтобы простой в техническом плане сайт отжирал на сервере 100 мегов и иногда падал? Работать нормально он мог только за очень агрессивной проксей, которая тупо кешировала все на существенное время. Но это тоже не выход.

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

                                                                                                    После зопы Django мне показалось землей обетованной, к которой я шел 40 лет :)
                                                                                                    Правильное разделение на компоненты — тут у нас ОРМ, а тут шаблоны. Если шаблоны не нравятся, можно заменить на свой движок. Данные отдельно — в базе. К которой ты сам можешь независимо подключаться и работать с ней. Проблема интеграции с другими системами просто отсутствует — льешь в базу, забираешь из базы. Правильно реализованный unix way. Каждый компонент на своем месте. Все файлы скрипты и прочее — в файловой системе, а значит и фтп и svn работают как надо.

                                                                                                    > Да и настолько ли хорош какой-нибудь Drupal?
                                                                                                    Он лучше как минимум в одном — он не пытается вобрать в себя слишком много.
                                                                                                    • 0
                                                                                                      Ну нет больше большого Zope перед вами :) Не волнуйтесь вы так :)

                                                                                                      Между прочим, даже Django обвиняли в попытках заново изобрести велосипед. А велосипед получился — ого-го!

                                                                                                      Статья-то к чему… Что затребовала душа программиста простую CMS, написанную на хорошем фреймворке и легко с ним интегрирующаяся. Получается, у меня есть и фреймворк хороший в качестве инструмента, и CMS прозрачная, и язык толковый. Оп-па! И жить хорошо!

                                                                                                      • 0
                                                                                                        > Ну нет больше большого Zope перед вами :)
                                                                                                        Я страшно рад, что скинул эту Зопу со своей дороги :)

                                                                                                        > Не волнуйтесь вы так :)
                                                                                                        Задели за живое. Душевные раны, полученные от общения с зопой, еще не зарубцевались :)

                                                                                                        > Оп-па! И жить хорошо!
                                                                                                        Да, вот теперь жить хорошо. :)
                                                                                                      • 0
                                                                                                        А можно к джанге-цмс подключить haml в качестве шаблонов?
                                                                                            • 0
                                                                                              Спасибо за статью, хорошая.
                                                                                              Удивительно вообще, что на Django вменяемая CMS появилась не так давно.
                                                                                              А из CMS на Django есть ещё загадочная и никем невиданная www.ellingtoncms.com/ (коммерческая)
                                                                                              • 0
                                                                                                Статья интересная.
                                                                                                Как небольшое дополнение
                                                                                                Однако, Питон — язык универсальный; интересных фреймворков на нем больше (чего только Twisted стоит);


                                                                                                Twisted — интересный, но не уникальный :) В Руби есть похожий EventMachine
                                                                                                • 0
                                                                                                  Ну да, только EventMachine существенно моложе и меньше.

                                                                                                  Насчет качеств самого фреймворка не знаю — не пробовал.
                                                                                                  • 0
                                                                                                    Ну да Twisted появился в 2002 году, а EventMachine в 2006.
                                                                                                    И да — в EventMachine протоколов реализовано меньше — зато среди тех, которые реализованы — есть те, которых в Twisted нет :)
                                                                                                    • 0
                                                                                                      Ну вы же понимаете, что шесть лет разницы априори дает мне гораздо больше всяких «зато» :)
                                                                                                • +1
                                                                                                  строчку. /env/bin/activate
                                                                                                  я бы поправил на. ~/cms-project/env/bin/activate
                                                                                                  Xubuntu по умолчанию лезет в корневую директорию.
                                                                                                  • 0
                                                                                                    Спасибо, поправил. Очепятка. Там должно было быть не "/env/bin/active", а «env/bin/active». У вас абсолютный путь, это тоже нехорошо.

                                                                                                  • +1
                                                                                                    > sudo apt-get install python-setuptools python-dev build-essential

                                                                                                    Надо добавить python-virtualenv
                                                                                                    • +1
                                                                                                      >> sudo apt-get install python-setuptools python-dev build-essential
                                                                                                      > Надо добавить python-virtualenv

                                                                                                      И еще python-pip
                                                                                                      • 0
                                                                                                        поправил
                                                                                                        • 0
                                                                                                          Может, лучше так?

                                                                                                          easy_install pip
                                                                                                          pip install virtualenv

                                                                                                          а то будет старье разное устанавливаться
                                                                                                          • 0
                                                                                                            Старье — это вы про версию pip?

                                                                                                            А мне вот кажется, что, к примеру, в ubuntu пакеты довольно свежие, и ставить вне apt пакеты в систему — нечистоплотно.
                                                                                                            • 0
                                                                                                              Мне кажется, это не принципиально, всего-то будем иметь более свежую версию pip. Но, по крайней мере, устанавливать pip, и другие пакеты, нужно или из репозитариев, или так, чтобы они не путались с системными пакетами, иначе смысл всей затеи теряется.
                                                                                                              • +1
                                                                                                                Мне тоже кажется, что лучше или все пакеты ставить через pip, или все через apt, чтоб не путалось. Но через apt доступны неактуальные версии, и не все там есть, и это такая принципиальная штука, которая со временем не исправится. Поэтому, как мне кажется, выход в том, чтобы ставить все через pip, причем, желательно, в virtualenv.

                                                                                                                Последний pip умеет uninstall, к примеру.

                                                                                                                Ну да, есть еще такой вариант: ставим pip и virtualenv через apt, потом создаем virtualenv и там выполняем pip install -U pip. И потом питоньи пакеты никуда кроме virtualenv'ов не ставить.
                                                                                                          • 0
                                                                                                            А есть где-нибудь живой пример качнуть, а то что-то нихера не получается? Всё поставил, захожу на локалхост, а там:

                                                                                                            «It worked!
                                                                                                            Congratulations on your first Django-powered page.

                                                                                                            * Start your first app by running python demosite/manage.py startapp [appname].»
                                                                                                            • 0
                                                                                                              Собственно, а в чем проблема? Вроде как запустился, можно работать.
                                                                                                              • 0
                                                                                                                итворкс — я так понял это стандартный ответ джанги. А джанго-цмс я не вижу.
                                                                                                                • 0
                                                                                                                  Наверное что-то не так делаю.
                                                                                                                  • 0
                                                                                                                    Очень похоже, что вы не подключили приложение cms в settings.py. Естественно, после этого надо сделать syncdb.

                                                                                                                    Напишите, проделали ли это и создал ли syncdb после таблицы, связанные с cms?
                                                                                                                    • 0
                                                                                                                      Да, ладно, сначала почитаю книгу по джанге, чтобы быть в курсе как эта кухня работает.
                                                                                                              • 0