Давно хочу написать про Django. В итоге, вот, сподвигся, прочитав песню о Ruby и Rails на Julik Live.

Многим людям, особенно занимающимся программированием, дизайном и прочей деятельностью, связанной с hi-tech творчеством, думаю, знакомо ощущение, что ты в этом мире катастрофически не успеваешь за временем. Что, в общем-то, и понятно: благодаря интернету творческим людям делиться интересными мыслями становится крайне просто. Усваивать такое количество информации одному человеку почти нереально, поэтому все мы, наверное, осознанно или нет, выработали какие-то механизмы фильтрации, по поводу чего можно просто подумать "да, прикольно...", а чем заинтересоваться поподробнее.

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

"Таки" в словах "таки пошел" означает, что я, в общем-то, не особенно западаю на объявления о новых веб-фреймворках. Действительно их существует просто дикое количество. Такое ощущение, что каждый веб-разработчик считает своим святым предназначением выдрать куски кода из какого-то своего очередного сайта и объявить их тулкитом, фреймворком, CMS или чем там еще... Документация не прилагается, рефакторинг — "планируется". Нет, безусловно есть и хорошие, и даже, наверное, очень много. Но обилие плохих поделок сильно снижает вероятность благополучного исхода знакомства.

Но с Django у меня вышло иначе. Я не только про него прочитал, но и решил после этого даже с ним поработать! Что еще более невероятно, я, который может с легкостью рассказать, чем я по уши загружен на ближайшее десятилетие, все же начал с ним работать. И уж совсем из области фантастики то, что все не остановилось на уровне прототипа в моем ноутбуке, а движется к завершению в виде коммерческого проекта фотосервиса (не спрашивайте подробней, что за проект: не могу говорить).

Ruby on Rails

Если вы занимаетесь web-разработкой, умеете пользоваться интернетом и не считаете, что ASP.NET или PHP — самое последнее слово в веб-технологиях, то вы слышали о "Ruby on Rails". Трудно было не слышать, потому что восторгов и отзывов по поводу того, как просто, быстро и без потери масштабируемости можно писать на RoR веб-приложения, в сети — море.

Меня огорчало только одно: какое-то время назад, решив поменять ориентацию, я заинтересовался не Ruby, а Python'ом. И возможно, я уже слишком "старый" по программерским меркам, поэтому начинать учить другой язык, не разобравшись с первым, мне стало лениво. Да, в общем-то, и смысла особенного не видел, потому что Питон, как язык, очень мне нравится.

Но так или иначе, не успев даже как следует обидеться на судьбу за то, что соседняя очередь опять идет быстрее, я читаю про Django, о котором, как только он появился, говорят не иначе как "очень похоже по идеологии на RoR" и "как RoR, только для Питона". Это, после совета авторитетов, стало вторым побуждающим фактором к скачиванию.

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

Философия Django

Вот где Django сходится с Rails, так это в идеологии (от чего, собственно, их все и сравнивают). Вот основные принципы Django.

И еще там есть много вкусных вещей, которые заставляют вас, читая, кивать головой, думая "ага, правильно!" :-).

Less code

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

Для достижения этого многие вещи делаются без лишних указаний в настройках, а по соглашению. Скажем, если надо при генерации схемы БД заполнять ее какими-то тестовыми данными, нужно просто оставить в проекте файл оговоренного названия с SQL-скриптом, не надо нигде прописывать выполнение этого кода.

Кроме того, Django поставляется с немалым количеством уже написанных базовых вещей, которые в том или ином виде присутствуют почти в любом современном веб-приложении:

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

Но пожалуй, самая "презентационная" особенность Django, ускоряющая разработку сайта — админка. Все, кто пишет веб-приложения, знают сколько времени может отнять написание рабочего места для человека, который будет рулить наполнением табличек. А если это еще и на права завязано...

В Django для этого писать код вообще не надо. Надо только указать, какие ваши объекты вы хотите видеть в административном интерфейсе и все, Django автоматически формирует интерфейс, который мало того, что работает, так еще и выглядит классно.

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

Python

Не последнюю роль в реализации принципа "меньше кода — больше денег" играет язык программирования.

Питон — один из модных объектно-ориентированных динамических языков, который отличается от классических (Паскаль, Си, Си++) в первую очередь тем, что он современный. А значит, в нем исправлены многие вещи, которые были сделаны в тех языках плохо. Кроме того, многие приемы программирования (паттерны), которые сложились за долгое время, добавлены прямо в синтаксис языка.

Причем все это сделано не сумбурно, а с наличием четко выверенной позиции, что делает программирование несказанно более простым и предсказуемым. Одни из главных принципов Питона: "явное лучше неявного" и "должен быть только один очевидный способ делать одну вещь". Поэтому он и не превращается в Perl, который известен как "write-only language".

Django использует возможности Питона на всю катушку. Например взможность по объекту узнать всю внутреннюю структуру класса, какие у него методы и свойства, очень полезна для реализации принципа DRY. Именно из-за этого возможно строить модель данных по описанным классам и обвешивать объекты этих классов всякими полезными методами. Например, если вы определили класс Person с атрибутом picture, в котором лежит фотография человека, то Django сделает ему удобные методы get_picture_url(), get_picture_filename().

Буквально недавно я написал один кусочек, которым хочу поделиться в качестве примера совместной работы Django и Питона.

Есть у меня список объектов — уменьшенные копии фотографий — которые я передаю в шаблон. Мне понадобилась оптимизация, чтобы некоторые thumbnail'ы нужно было не передавать полностью, а использовать только их id.

Вот тут начинает работать Питоновская динамика. В список thumbnails я могу класть не только экземпляры класса thumbnail, а вообще говоря, все что угодно. И вместо целиковых thumbnail'ов я могу положить там где надо заглушки с id:

thumbnails=[]                  #создается пустой список
for t in get_thumbnail_list(): #получаются thumbnail'ы из БД
  if <какое-то условие>:
    thumbnails.append(t)
  else:
    thumbnails.append({'id':t.id})  #заглушка в виде стандартного dict

dict - это тип данных в Питоне, который в PHP известен как "массив", в Perl - как "хеш", а в C++ ближайшим аналогом является STL'ный "map".

В самом шаблоне ко всем элементам списка я обращаюсь одинаково: {{thumbnail.id}}, даже несмотря на то, что это по природе совсем разные объекты.

Работает это так. Когда Django'вский шаблон встречает конструкцию {{thumbnail.id}} он делает несколько проверок: 1. Если объект thumbnail - коллекция, и у нее есть ключик 'id', достается значение по ключу. 1. Если у объекта thumbnail есть свойство id - берется его значение. 1. Если у объекта thumbnail есть метод id(), то он вызывается и берется его результат. 1. Если бы вместо "id" была цифра, то Django проверил бы еще и элемент списка с этим индексом.

Вкусно, да? :-). В итоге шаблон получается гораздо более читаемым, чем во многих других шаблонных системах.

Дальше — больше. Мне понадобилось, чтобы в списке каждый thumbnail сопровождался еще одним параметром — признаком unchanged. И если добавить в заглушку еще один ключик проблем не представляет (будет {'id':t.id,'unchanged':False}), то у объекта thumbnail никакого такого свойства "unchanged" нет.

В каком-нибудь языке со статической типизацией надо было бы заменить все объекты в списке на некую обертку с дополнительным полем:

ThumbnailWrapper={
  unchanged:bool;
  object:Thumbnail;
}

... и заменить все обращения к элементам списка с просто thumbnail.id на thumbnail.object.id.

В Питоне же можно прямо к существующему объекту просто навесить новое свойство простым присваиванием:

thumbnail.unchanged=True   # у объекта создается новое свойство

Красота!

О стабильности кода

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

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

В заключении

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

Планирую писать про Django и дальше. Спрашивайте, что вам было бы интересно.

Комментарии: 63 (feed)

  1. MajestiC

    Вот найти что-нибудь такое для PHP, только нормальное =)

  2. Иван Сагалаев

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

    Честно говоря, совершенно серьезно советую начать питонить. Никакой экзотике в языке нет, наоборот, если у человека "программистские" мозги, язык этот обычно очень нравится.

  3. DenD

    Да, весьма интересно.
    Обязательно надо посмотреть на локальной машине.
    Хотя ближайшее время с php уходить пока никуда не собираюсь.

    Хотелось бы подробней узнать о создании на Django сложных фронтофисов. Насколько полно админка позволяет управлять объектами?

  4. Влад

    Разглядывал RoR, посмотрю и Django.
    одно печалит - как заставить хостера что-то менять в настройках? :)
    Это практически нереально :(

  5. Алексей Захлестин

    Вот я как раз пишу такую штуку на PHP 5.1 :)
    получается красиво.

    на 4 и даже 5.0 было бы не так красиво — PHP растёт

    но разработка закрытая. все открытые просмотрел: глюк на глюке :-(

  6. Yura Ivanov

    Интересно, смотреть нет времени. Несколько вопросов:

    Системные требования? MSSQL&IIS можно?

    Как происходит взаимодействие с базой? Смотрел, например, Битрикс (на php), при обработке больших выборок происходит request-timeout - медленно массивы работают (проблема не в хостинге, а в самом битиксе). Например, каталог товаров в 1000 позиций со сложной структурой категорий и свойств уже неповоротлив. У нас клиенты с номенклатурой только в 10-12 тысяч позиций...

    Ну и... ссылки на работающие проекты есть? ;)

  7. MajestiC

    Кстати, Maniac, в 6-ой версии уберут эти все недочеты пхп, насчет того что каждый кодит как он хочет (если знаешь, то там уже не будет register_globals, safe_mode, magic_quotes)... Кароче уберут работы криворуких программеров.

  8. MajestiC

    Если кому интересно, вот ссылочка с ноябрьской встречи разработчиков PHP.

    http://www.php.net/~derick/meeting-notes.html

  9. [...] PS. На тему Python’а в применении к webdev’у сейчас не осилил. Лучше сделаю отдельный пост. А пока, можно прочитать про Django у Maniac’а в блоге. [...]

  10. Иван Сагалаев

    Не ожидал такого ажиотажа :-). Сейчас кратко поотвечаю, потом еще пост напишу про работу с БД.

    • Админка позволяет менять все таблички, которые скажут.
    • Для Django нужно:
      • веб-сервер (Apache, lighttp, IIS)
      • Python 2.3+
      • mod_python или любой другой аналогичный механизм запуска скриптов, для которого в Питоне есть wsgi-связка (FastCGI, SCGI). Не знаю точно, что есть для IIS, но наверняка есть.
      • PostgreSQL, MySQL, SQLite. Поддержка MSSQL через ADO присутствует в виде бета-версии (собираются до Django 1.0 доделать). Кто-то пишет Oracle'овый драйвер, но его еще никто не видел.

    Список работающих сайтов: http://code.djangoproject.com/wiki/DjangoPoweredSites
    Сами разработчики говорят, что по практике работы их собственных сайтов - Django очень быстрый. Причем говорят, что именно очень :-). Сам ничего про это сказать не могу, потому что мой проект крутится на дохленьком тестовом сервере, и у него 1 юзер :-).

  11. mikv

    MajestiC, для PHP можно найти нечто похожее. Но не настолько мощное.
    CakePHP (http://cakephp.org)

  12. Иван Сагалаев

    Вот прямо горячий сегодняшний пример, как разработчики Django говорят о его скорости: http://www.djangoproject.com/weblog/2005/dec/08/congvotes/

  13. Voldemar

    Несколько не в тему, но тем не менее позволю себе поворчать :-)

    В список thumbnails я могу класть не только экземпляры класса thumbnail, а вообще говоря, все что угодно. И вместо целиковых thumbnail’ов я могу положить там где надо заглушки с id:

    Ага, а теперь пользователь списка должен знать (и это нигде явно не сказано!), что в списке лежат фактически ТОЛЬКО айдишники. Это не проблема для локального кода. Но как только ты отдаешь этот список неизвестному потребителю, начинаются проблемы.

    В Питоне же можно прямо к существующему объекту просто навесить новое свойство простым присываниванием: thumbnail.unchanged=True

    Ага, а что будет, если мы позже добавим свойство unchanged в исходный класс? Или вдруг коллега в своем куске кода добавит к классу свойство с тем же именем, но другой семантикой?
    Проблема таким вот образом используемых "динамических фишечек" в том, что они как раз увеличивают количество неявностей на квадратный метр, от которых мы, казалось бы, хотели уйти. И для больших команд это убийственно: передача кода новому разработчику означает что, ему придется перелопатить ВЕСЬ проект, для того чтобы найти откуда "растут ноги" у отсутствующего вроде-бы у класса свойства. Особенно актуальна проблема в отсутствии IDE с поддержкой языко-ориентированных инструментов поиска/рефакторинга. Все-таки дефиниции и контракты лучше локализовывать в одном месте, ИМХО.
    С другой стороны, хорошо систематизированный и документированный фреймворк только выигрывает от возможности опереться на подобный динамизм языка. А наличие популярного фрейморка к тому же поможет упростить общение разработчиков, расширяя их словарь введенной фреймворком дополнительной семантикой.
    Я все к тому, что при работе с динамическим кодом разработчикам нужно соблюдать определенные правила, которые будут помимо прочего исполнять роль обычно делегируемую компилятору в языках со статической типизацией. Кстати, Ваня, может ты уже встречал подобные best-practices?

  14. Иван Сагалаев

    Ты затронул тот пласт, который я как раз старательно стирал из статьи, чтобы не будить лихо :-). Действительно, разность в подходах динамического и статического типизирования - тема отдельная. Обещаю, что напишу по твоему комментарию отдельный пост, где постараюсь сформулировать свои мысли.

    Насчет best-practices... Я не настолько давно вожусь с веб-разработкой на Питоне, поэтому каких-то хороших источников не укажу. Но точно знаю, что вся целостность больших проектов на Питоне строится на двух вещах: тесты и doc-строка. Тесты, они тесты и есть, про них уже все написано.

    А doc-строка - это такой формализованный комментарий, который вставляется в начало модулей, классов и функций, в котором написано, что этот объект делает, какой у него интерфейс. Принципиальное его отличие от просто комментария в том, что в языке есть стандартный доступ к нему, и любая вменяемая IDE, как только ты пытаешься использовать функцию, тут же показывает тебе ее описание с этим текстом. То есть, очень простая штука, но она дает сумасшедшую пользу, сводя всю документацию к точке редактирования, и избавляя от ползания по всему коду.

  15. Stoune

    Насчёт best practices для Питона то єсть
    PEP: 8
    Title: Style Guide for Python Code.
    Ещё для тех кто переходит с языков с статической типизацией посоветую http://dirtsimple.org/2004/12/python-is-not-java.html
    А вообще мне непонятны очередные радости насчёт ещё одного фремворка. Чем он лучше стабильно работающего и заведомо более мощного плюс доведённого до комерческой готовности Zope или построеного на его базе Plone?

  16. [...] Возможный инструментарий: Имеет смысл посмотреть в сторону Django (Python), либо каких-либо PHP-framework-ов. Здесь подробно про Django. Для web-разработок также очень и очень рекоммендуют Ruby on Rails, но это совсем уже непаханная целина. [...]

  17. hodza

    Я некоторое время программировал на asp.net также знаю python. Собираюсь в маленьком городки отрыть онлайн магазин. Ну оочччеенььь маленький. :). Но возможно он перерастет в нечто большое. Мне как разработчику охота чтобы мог изменять все и в тоже время мне нужна высокая скорость разработки. Что вы мне можете посоветовать. Zope plone изучать или остановится на jango или продолжать asp в mono? Мой уровень в веб новичок. Так что извините заранее за возможно некорректный вопрос.

  18. Иван Сагалаев

    Я думаю, Django для вашего случая буквально "прописан" :-). Его одновременно и очень просто изучать, и в то же время он позволяет писать системы очень больших масштабов. Единственное, о чем надо знать на сегодняшний момент - он еще не достиг версии 1.0 и активно меняется. Я сейчас делаю один коммерческий проект на Django, и периодически в фреймворке делаются изменения, под которые надо менять свой код. Это, между тем, довольно простая задача, потому что все изменения с подробными описаниями, что надо менять, документируются. Но к этому надо быть готовым :-).

    Zope советовать не буду. Это очень большая штука, "мир в себе" со своими правилами. Тем, кто там уже живет, эта система, наверное, и удобна, но для новичка это совсем не подходит.

    Про ASP сказать ничего опредленного сказать не могу - не видел. Единственное, на уровне интуиции идея использования ASP.NET в неродной среде (Mono) кажется мне ненадежной. Боюсь, замучают всякого рода мелкие несовместимости.

  19. hodza

    Спасибо помучаюсь с jango уже все скачал. Если не воткнет. Буду терзать Zope или mono

  20. hodza

    Кстати asp.net в mono довольно приличная. Некоторые изменения в сравнении с дот нет фреймворк есть но не существенны. ORM тоже есть.

  21. [...] Узнать поближе Python я хотел давно, но все никак не складывалось. А тут решил надо, тем более, что после рассказов Ивана Сагалаева о вкусностях Django, не попробовать их самому было невозможно. [...]

  22. [...] Django [...]

  23. Pavel Ivanov

    Большое спасибо за обзор. Большая работа! :-)
    Правда, если до прочтения я был уже одной ногой в Ruby и RoR, то сейчас меня сново отнесло назад на распутье :-)

  24. Micahel

    Классный обзор - Многим поможет выбрать что использовать.
    Последние 2 -3 года возился с Zope - до недавних пор. Возникла задача сделать один проект в короткие сроки - и тут Джанго как раз в тему -даже переписал пару apps из Zope в Джанго - причем потратил времени намного меньше чем это делал в Zope. Воощем Джанго очень удачный framework!

  25. Egor Margineanu

    Спасибо за статью.
    Очень интересно было прочитать про особености этого фрэймворка. Давно хочется пересесть на более легкие платформы, но клиенты все Lotus Domino да WebSphere Portal хотят. :-)

  26. Atl

    Спасибо за написанное!
    Ничего не понятно, но ладно - человек же писал. Слишком много в последнее время в Инете статей подобных появилось.
    "Как вешать в граммах", т.е. как ставить этот Django под WinXP? Читать по инглишу умеем. Zope поставил и ковыряю. Plone - работает.

    Как ставить Django?

  27. user

    можно ли использовать Django как cgi (без mod_python к Апач или Fast-CGI)

    переход на Fast-CGI может оказаться сложным (придется ли в приложения что-то добавлять или в Django это происходит прозрачно)

    можно ли подключится к серверу nginx (через Fast-CGI)

  28. Иван Сагалаев

    можно ли использовать Django как cgi (без mod_python к Апач или Fast-CGI)

    И да, и нет. "Да" в том смысле, что работать оно будет, а "нет" в смысле, что время отклика на запросы будет доходить до десятков секунд, что неприемлемо. То есть в результате - нет. Какая-нибудь штука, держащая загруженный код в памяти все равно понадобится.

    переход на Fast-CGI может оказаться сложным (придется ли в приложения что-то добавлять или в Django это происходит прозрачно)

    Прозрачно. В Питоне есть общий стандартный протокол (WSGI), которым он общается с веб-сервером. Django его поддерживает, поэтому с ним можно свободно менять как веб-серверы, так и серверы приложений (FastCGI, SCGI).

    можно ли подключится к серверу nginx (через Fast-CGI)

    Да. Также как и с lighttpd, и с тем же Апачем. У меня на форуме это в свое время очень подробно обсудили: http://softwaremaniacs.org/forum/viewtopic.php?id=158

  29. skru

    произвольное условие типа "равна ли длина списка пяти" — не допускается

    Это позволяет сделать стандартный фильтр "length", примерно так:
    {% ifequal mylist|length 5 %}

    в шаблон проникает довольно много логики, которой неплохо бы быть на уровне приложения

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

    Пример. В шаблон передается переменная age, где хранится возраст, и нужно в зависимости от последней цифры этого числа подставить {{age}} "лет", "год" или "года".

    Удобно было бы прямо в шаблоне вычислить остаток от age, присвоить его новой переменной и сделать ветвление. В Django приходится перекладывать это в программный код, что с точки зрения MVC неправильно. Ветвление if-else сэмулировать можно, но выглядит это ужасно.

    В других случаях такая ограниченность часто приводит к дублированию кода.

    Допустим, есть два экземпляра одного класса Person: 'her' и 'him', в каждом из которых имеются поля 'name' и 'color'. Если надо обработать их одинаково, целесообразно использовать один и тот же include (фактически, он выступил бы в роли функции). Что-нибудь в духе:
    {{color}} Player: {{person.name}}

    Чтобы передать her и him в этот include как person, приходится идти на ухищрения — скажем, "заворачивать" каждый объект в отдельный список и в шаблоне применять для каждого цикл, из одной итеррации:
    {% for person in list %}
    {% include ... %}
    {% endfor %}

    В общем, систему шаблонов Django я считаю одним из ее слабых мест.

  30. Иван Сагалаев

    Пример. В шаблон передается переменная age, где хранится возраст, и нужно в зависимости от последней цифры этого числа подставить {{age}} “лет”, “год” или “года”.

    Удобно было бы прямо в шаблоне вычислить остаток от age присвоить его новой переменной и сделать ветвление.

    Есть совсем другое, django'вское решение: сделать фильтр или тег, который будет содержать эту логику. Вроде {{ age|age }}.

    Основной смысл убирания логики как раз избежать вот этих вот ветвлений, которыми полны другие шаблонные системы. С точки зрения дизайнера само ветвление - это деталь реализации того, что он действительно хочет сделать: вывести возраст. Это действительно шаблонная логика, но место ей — в Питоне, а не среди HTML'ных тегов. Потому что это более низкий уровень логики, чем оформление страницы.

    Допустим, есть два экземпляра одного класса Person: ‘her’ и ‘him’...

    Этого примера, честно говоря, не понял. Если объясните подробней, опишу как это принято в Django делать.

    В общем, систему шаблонов Django я считаю одним из ее слабых мест.

    Это от того, что Вы всеми силами игнорируете ее основную черту: убирание низкоуровневой логики из шаблонов и стараетесь все равно свести все к управляющим императивным конструкциям. Конечно оно выглядит криво :-). Потому что не предназначено для такого.

  31. skru

    Есть совсем другое, django’вское решение: сделать фильтр

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

    Это от того, что Вы всеми силами игнорируете ее основную черту: убирание низкоуровневой логики из шаблонов

    Я полностью согласен с тем, что слишком много логики в шаблонах (как, например, в Cheetach или DTML) — это плохо. Но слишком мало — ничуть не лучше. Если вообще убрать логику и шаблонов, от них ничего не останется. Это вопрос меры.

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

    • дублирования кода
    • лишних операций

    Если в языке есть "if", не вижу смысла исключать "else". Если есть for и loop-переменная, то почему бы не разрешить объявлять переменные в других местах?

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

  32. Иван Сагалаев

    Не думаю, что стоит делать фильтр ради одного частного случая.

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

    Кроме того, этот случай — далеко не частный. Красиво написать возраст может понадобится и в других проектах. Именно этим Django и поощряет создание библиотечных функций, а не бесконечный copy-paste как-бы-частных случаев, которым полно веб-программирование.

    Если в языке есть “if”, не вижу смысла исключать “else”. Если есть for и loop-переменная, то почему бы не разрешить объявлять переменные в других местах?

    В Django-шаблонах просто не такие критерии. Для специалистов (дизайнеров, верстальщиков), которым этот язык шаблонов предназначен не близка мысль о том, что слово после "for" — это переменная, к которой что-то присваивается. И они не думают, что наверное общая абстрактная операция присваивания была бы полезной. Это чисто программистское упражнение. Для человека же, работающего над шаблоном нужно просто понятие "вывести все заказы/людей/операции". Они не должны думать на деталями реализации.

    P.S. Кстати, else там никуда не делся.

  33. skru

    Для специалистов (дизайнеров, верстальщиков), которым этот язык шаблонов предназначен.

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

    По правде сказать, мне трудно себе представить не-программиста, который писал бы темплейты — будь то Django, HTML::Template, Smarty или что-то еще.

    P.S. Кстати, else там никуда не делся.
    Ой, прошу прощения, я конечно, имел в виду "else if".

  34. vlad

    Боюсь буду не первым, т.к. до конца комменты не дочитал. Но в RoR есть такая штука как Migrations, которая как раз и предназначена для создания и управления БД из ЯП, поэтому ставить в минус RoR'у

    там сначала пишется схема БД

    нельзя

  35. Иван Сагалаев

    Я никоим образом не ставил это в минус... Наоборот, сказал, что вот есть два разных подхода, и все.

  36. a_g_barnaul

    Очень непонятно, когда ожидать версию 1.0..?
    Хотябы приблизительно?

  37. Иван Сагалаев

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

  38. dervish

    Здравствуйте.
    Очень интересный материал, спасибо за труд:)
    Хотелось бы узнать, кто из отечественных хостеров поддерживает этот фреймворк. Мною был найден пока только СНГ-вский tophost.com.ua
    Хотелось бы найти что-то поближе к москве;)
    Если есть такая информация, буду признателен за письмецо с сылочкой))

    Максим

  39. Денис Барушев

    ... система прав на объекты вашей модели данных, генерация паролей...

    В тоже время вот такая ветка в разработке у них есть:

    RowLevelPermissions: Currently Django's permission system only works at the level of an entire model — e.g., user "Bob" has access to add flatpages and edit users. This Summer of Code project will extend the permission system to be much more fine-grained, so permissions will be able to be assigned per object instead of per model (so, for example, user "Bob" could be given permission to edit only flatpage number 24 and user number 12, instead of all flatpages and all users).

    http://code.djangoproject.com/wiki/RowLevelPermissions

    Так все таки per object или per model?
    Если есть время, очень бы хотелось увидеть пост в блоге по поводу работы системы прав в Django и ее практического применения.

  40. Иван Сагалаев

    На модель. Ветка с пообъектными правами нынче слегка покинута... Пост я такой вряд ли напишу, потому что ни разу встроенными permission'ами не пользовался. Я вообще не большой фанат прав в ACL-стиле, предпочитаю "ролевые" права, которые привязаны не к моделям, а к операциям над системой.

  41. Vyacheslav Shindin

    Для новичка Django+jQuery в самый раз, хороший RAD инструмент. Но для гибкого проекта лучше pylons+sqlalchemy+mako, так же: paster, routes(порт с RoR), и многое другое.

  42. Александр Соловьёв

    Было бы интересно услышать аргументы. А то я ни одного, кроме ORM, не вижу.

  43. Иван Сагалаев

    Я, честно говоря, и про ORM бы не начинал :-).

    Но вообще, комментарий в такой неконкретной постановке обсуждать просто нереально, по-моему.

  44. Алексей Гусев

    Было бы интересно услышать аргументы. А то я ни одного, кроме ORM, не вижу.

    :-) Вспоминается один профессор, которому слали доказательства теоремы Ферма. Он так замучался писать ответы, что заказал в издательстве листочки с текстом (примерно): «Здравствуйте, уважаемый ...! Спасибо Вам за вашу попытку доказать теорему Ферма, но в на ... строке ... страницы Вашего доказательства ошибка, делающая его несостоятельным».

    Так и в случае аргументов «за джангу» предлагаю каждому джангисту завести в блоге страницу «почему джанго» и закидывать линками в ответ на такой вопрос :-)

    P.S. Александр Соловьёв, надеюсь,вы не нашли негатива в моем комментарии. Его там нет :-)

  45. Александр Соловьёв

    P.S. Александр Соловьёв, надеюсь,вы не нашли негатива в моем комментарии. Его там нет :-)

    Не, не нашёл. :-) Наверное, так и сделаю.

  46. Сергей

    Прочитал обзор, понравилось.
    Мое сугубо личное, Django очень быстр (поверьте в Google редко ошибаются), я имею ввиду то, что большинство сервисов Google работает на Py. Из выступления на РИТ 2007, я могу сделать вывод, что Yandex тоже находился долгое время в поисках и видать их окончательно достал Perl, и они активно продвигали Django на РИТ 2007. (продвигали не в плане продвигали, а вполне аргументированно продвигали). Еще радует, что mod_python и все тебе есть и работает прекрасно. Отсутствие книг, руководств итд не радует, RoR в этом плане более продвинут.

    По поводу Flame Wars on PHP могу сказать одно, мне тоже не нравиться, но популярно мать его ... попсово и этим все сказано, работает как автомат калашникова, в любую погоду везде и всегда -)

    RoR - хорошо, но Хостинг это проблема номер раз, Capistano это проблема номер два, deploy проблема номер три, многие приходят к выводу что для масс хостинга mod_ruby как то не катит. Мне ситуация с RoR сейчас, напоминает ситуацию с ASP.NET в далеком 2001 году, когда хостинг на ASP.NET + MSSQL 2000 стоил под 60$ в месяц и проблем была куча начиная с того что не многие хостеры соглашались закидывать к себе что либо в GAC, заканчивая тем что .NET не было книжек описаний итд. Разработчики RoR предусмотрели это, но проблема с хостингом остается открытой. Кроме того посмотрите как RoR работает с БД.

  47. Atl

    Прошло чуть больше 2-х лет с моего последнего обращения. Ничего так и не изменилось - толковое описание по установке Джанго не появилось.
    Наверно уже никогда не появится.
    :)))))))))))))))))))

  48. Иван Сагалаев

    Я правильно понимаю, что вы думаете, что тот комментарий (да и этот тоже) должен был побудить кого-то написать специально для вас такое описание? Простите, но это и правда напрасно. Кроме того, если вы ждете два года ответа здесь, не попытавшись набрать простой запрос в Google, то похоже, сам ответ вас не так уж и интересует...

  49. Guest

    :-) Вспоминается один профессор, которому слали доказательства теоремы Ферма. Он так замучался писать ответы, что заказал в издательстве листочки с текстом (примерно): «Здравствуйте, уважаемый ...! Спасибо Вам за вашу попытку доказать теорему Ферма, но в на ... строке ... страницы Вашего доказательства ошибка...

    Наверное Уайлс тоже получил етот шаблон ;)

    Шутки в сторону! Гугель указал, что требуется в большинстве случаев!

  50. magnit

    Про шаблоны.

    Допустим в базе есть цена товара 12345.34.
    Мне нужно отобразить ее с разделением вида 12 345.34
    Я считаю что это задача исключительно шаблонизатора, потому как это именно представление, а не логика.

    Пишу на пхп. Использую XSLT.

    А как это сделать на джанго?

  51. igorekk

    Написать свой фильтр, который будет формировать строку с нужном виде

  52. Иван Сагалаев

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

  53. EvgIq

    Если кому интересно - мой опыт начала работы с Django на
    http://www.burdin.interwood.ru
    Написал специально из-за того, что сам промучился месяц. Не просто с установкой, а вообще как "правильнее" начать.
    Оговорюсь - для пользователей Windows.
    И вторая оговорка "правильнее" - не факт еще :)
    Может кому пригодится...

  54. Dym Popov

    Совершенно тупой вопрос, за который мне очень даже стыдно, но он настойчиво меня мучает, а ответа никак не нахожу, хотя, возможно, тупо не вижу по типу "смотришь в книгу, видишь фигу" :)

    Так вот. Где можно найти сторонние компоненты для django? Просто у большинства CMS или фреймворков, обычно есть некbе комьюнити или каталоги расширений, где удобно находить уже готовые дополнительные компоненты, что бы самому не изобретать велосипед. Короче, по типу http://extensions.joomla.org/.

    Так вот, для django никак не могу подобного найти. Может и нет? Или я слеп?

  55. Ivan Sagalaev

    Центрального места нет. Есть:

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

  56. InvisibleMan

    Иван подскажите пожалуйста в какую сторону гуглить про это: "Скажем, если надо при генерации схемы БД заполнять ее какими-то тестовыми данными, нужно просто оставить в проекте файл оговоренного названия с SQL-скриптом..." Заранее спасибо!

  57. Ivan Sagalaev

    Скажем, если надо при генерации схемы БД заполнять ее какими-то тестовыми данными, нужно просто оставить в проекте файл оговоренного названия с SQL-скриптом...

    С 2005 года многое изменилось :-). В частности, вместо этого теперь используется fixture "initial_data".

  58. Маниакальный веблог про Django

  59. Evgeny

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

  60. Роман

    Спасибо ! Только начал изучать, и захотел разобраться что к чему. Ваша статья многое прояснила, хоть и прошло 7 лет !

  61. Денис

    Очень информативная статья. Как раз подходит для новичков, которые мечутся между Django и RoR.

  62. Джокер. Хорош на меня ведра гавна выливать. Это вообще с технической среде холивар - спорить, какой язык программирования лучше или фреймворк. То, что ты советуешь Акутагаве - я с этим не согласен, т.к. он изначально показал примеры довольно серьезных сайтов, которые работают всяко не на Вордпрессе или Джумле. А про Artisteer 4 я вообще молчу - это программа для фрилансеров. Хорошие и современные интерфейсы делаются при помощи Фотошопа, также, сейчас многие используют Twitter Bootstrap - это все более современно. Насчет твоих высказываний про Питон и Джанго и особенно про "китайского мастера" могу сказать, что тут ты показал свои знания очень хорошо. Питон чем хорош, что там практически не возможно быдлокодить (чем знаменит твой "очень современный PHP"). В отличие от пыхи - там минимум кода, он всегда понятен другому разработчику. В Джанго используется модель раздельного кода MVC - где сам код не встраивается в html. Не упомянул ты и об админке, в Джанго она автоматически генерируется и для наполнения сайта - это самый удобный вариант. Не понял, зачем ты пишешь про развод лохов. Я что, предлагаю свои услуги по разработке сайта на Джанге что-ли? Нам сайт делали на этой технологии, я ее более глубоко узнал за это время, полностью доволен функционалом, использую уже долгое время - поэтому и советую. Это очень хороший вариант и для небольших проектов, хотя бы из-за того, что в них код простой и понятный, очень удобная админка (намного меньше времени уйдет на разработку), то, что код разделен от представления. Даже на офсайте написано: "Django является веб-фреймворком высокого уровня на Питоне, который поощряет быструю разработку с чистым прагматичным дизайном". Если ты про готовые модули - на Джанго их куча, пару строчек кода и новое приложение в работе. "PHP довольно современен" - здесь ты опять свои знания поверхностные показываешь - он по многим параметрам тому же Питону уступает - особенно своей громозкостью кода, что порождает быдлокодинг. Почитай Маниакальный веблог » Django P.s. Хорошо, что Ruby-on-Rails не предложил, тогда этот Шимпанзяка вообще съел бы меня вместо бананов.

  63. Татьяна Делик

    Картина давно поменялась instagram.com на Джанго (нагрузка весь Мир)

    https://instagram.com/

    ВОТ ОНО ЭТО ВРЕМЯ DJANGO ПРИШЛО В РОССИЮ. Государственные сайты пишут на Django.

    http://spb-tut.ru/info/history/?page=44

    Я, для себя долго решала. Хотя живу в Америке и у нас все повально учат Python.

    А вот, что меня убедило, почему Python и Django

    http://spb-tut.ru/guest/gt/

Добавить комментарий

Format with markdown