Вышел web.py 0.3

Спокойно, пациент, все хорошо.

Что ви понимаете под рекурсией и функциями применительно к шаблонизатору? Вы только не нервничайте :)

> не умеет рекурсию и функции,

Это обусловлено идеологией. Шаблоны - это представление, туда не суют сложную логику. Кроме того, функции легко приделать через модели.

Это не бенчмарк, а рекламные куплеты на офсайте сего шаблонизатора.

> Ради вагона джанговских удобств

Я этот вагон (а может и целый состав) могу найти и в других проектах. НИЧЕГО революционного и фантастического в джанге нет. Я не испытываю к ней неприязни, вижу в ней хорошие стороны, но не страдаю фанатизмом. Для маленьких простеньких сайтегов - лучшее решение, сложно спорить. Для чего-то более - не так все однозначно.

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

Ммм... Сублимация, кажется, так это дядюшка З.Ф. называл, а? :)

> Я этот вагон (а может и целый состав) могу найти и в других проектах. НИЧЕГО революционного и фантастического в джанге нет. Я не испытываю к ней неприязни, вижу в ней хорошие стороны, но не страдаю фанатизмом.

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

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

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

> Ему отвечают "ну вот тебе тесты"

Вот тут нестыковка. Мне другое ответили.

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

http://dev.pocoo.org/hg/jinja2-main/file/tip/examples/bench.py

===============================================================================

                       Template Engine BigTable Benchmark
===============================================================================

    This benchmark compares some python templating engines with Jinja 2 so
    that we get a picture of how fast Jinja 2 is for a semi real world
    template.  If a template engine is not installed the test is skipped.
-------------------------------------------------------------------------------

    jinja               0.0116 seconds
    mako                0.0126 seconds
    tenjin              0.0122 seconds
    spitfire            *not installed*
    django              0.4122 seconds
    genshi              0.4401 seconds
    cheetah             0.0466 seconds

Недавно профилировали свой сайт - на генерацию страниц из шаблонов уходило 80% времени - это уж ни в какие ворота не лезет. Это при том, что на каждую страницу делается по 10-20-30 SQL-запросов.

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

Тебе лично доказывать никто ничего не собирается. Если у тебя есть сомнения - проведи свои тесты.

А отставать в нашем деле нельзя вообще ни на день...

Мне незачем ничего тестировать - узкие места у меня совсем не в темплейтах. Но отставание в 40 раз - вы в это верите? Они их что, в GPU парсят штоле?

Это я запускал, дебаг выключил. =) Кстати, со включенным дебагом результат такой же.

>> не умеет рекурсию и функции,

> Это обусловлено идеологией. Шаблоны - это представление, туда не суют сложную логику.

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

Хотя, повторюсь, что с джанго не работал, для веба использую JEE, если брать местные шаблонизаторы, то нравится velocity и freemaker (пишу на нем шаблоны тегов для Struts 2).

TEMPLATE_DEBUG = DEBUG ?

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

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

И при чем здесь PERL??????????

class index:
    def GET(self):
        return "Hello, world!"


о_О А это разве удобно, создавать класс на каждый чих? где может быть оправдано? имхо так намного логичнее:

get '/' do
   "Hello, World!"
end

post '/' do
   "Hello, #{params[:name]}!"
end

Ойлоло. Пистонофаги изобрели сервлеты. И десяти лет не прошло.

а что мешает использовать свой render_to_response с блекджеком и нинзями:) ?

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

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

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

> а что мешает использовать свой render_to_response с блекджеком и нинзями:) ?

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

> К python для простых личных веб-проектов пока только присматриваюсь. Смотрю везде джанго хвалят. Но если ее шаблоны рекурсии не умеют, то это действительно плохо. Сразу приходит на ум красивый и аккуратный код генерации многоуровневого меню, генерить в модели "плоскую" структура не всегда удобно и красиво. Ну а без функций вообще не понятно как жить :)

ничто не мешает тебе заюзать сторонний шаблонизатор.

> ничто не мешает тебе заюзать сторонний шаблонизатор.

А смысл тогда использовать Django? Потом захочется сторонний ORM, потом сторонний маршрутизатор и т. д. Я б если сейчас начинал новый проект, которому не нужна джанговская админка, сразу взял бы Werkzeug.

я думаю народ проблему генерации шаблонов и т.п. решает кэшированием, поэтому не стоит так убиваться из-за результатов тестов. А 20 запросов на странице это совсем не плохо (опять же если кэшировать), большие готовые ЦМС делают сотни запросов. Но таки да надо стремиться к лучшему, но вот с тем же пилонсом как-то сыкотно работать.

У нас скорее CRM, чем CMS, кэшировать там и нечего.

А Pylons - это зло, по-моему, там столько всякой магии, что оно не может не ломаться.

Работаю с Django 2 года - если надо что-то сделать нестандартное, сразу вылезают бока. Два самых убогих компонента в Django это шаблоны и ORM. Простые вещи делаются просто и удобно.

Следующий проект хочу попробовать делать на Paste+WebOp+SQLAlchemy+Mako.

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

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

+1.

Турбогирс тоже вызывает неоднозначные оценки. Вроде бы проект и подавал надежды в свое время, но сейчас - ветка 1.х тупиковая, а ветка 2.х развивается слииишком медленно. Если вообще развивается :(

а оно только в режиме mod_python форкается?

> Ну поведай же мне пример охренительных шаблонов, которые по параметрам скорость/удобство делали бы джанговские.

Mako, Jinja2

http://lucumr.pocoo.org/cogitations/2008/09/16/why-jinja-is-not-django-and-wh...

> Я тебе привожу конкретный пример - невозможность декомпозиции моделей приложения (в рамках терминологии джанго) из модуля в пакет.

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

Сказочники, блин. Спорят о том, чего не знают.

Пользую Джангу в течении 2-х лет. Доволен.

Но! Она очень не подходит когда надо "натянуть" ее на уже готовую базу данных. Вот когда намашетесь то ! :(
Если с "нуля" - всё быстро, просто и надежно (ОМГ - я сказал "глобально и надёжно" да?)

Про джангины темплэйты ... тормозов за ними не заметил, впрочем стремительности - тоже :) Все кто ругают их "недостаточную функциональность" - 100% перцы типа человек-оркестр ... код пишут сами, css -сами, даже картинки сами рисуют :-) А как только у вас всем кроме кода занимаются другие люди ... страшные люди - дезиГнеры! - вы полюбите Джанговские темплейты горячо и нежно :)


GR.

PS: Но на werkzeug всё же посмотрю :)

Дизайнеры, которые пишут шаблоны - это утопия. На практике обычно бывает так: пишешь болванку, отдаёшь ему и говоришь: ВСЁ, ЧТО В ФИГУРНЫХ СКОБОЧКАХ - РУКАМИ НЕ ТРОГАТЬ! И то умудряются что-то поломать.

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

Надо вам превьюхи картинок делать, подключаешь какой-нибудь Nesh's Thumbnail и радуешься. Нужна отладочная консоль, где б показывались переменные в шаблоне, все sql запросы и прочие удобства? Подключаешь django-debug-toolbar. gravatars и openid тоже уже есть, бери и пользуйся.

Внутри тоже неплохие батарейки: хороший добротный contrib.auth с готовыми декораторами для вьюшек, ролями и группами, comments (есть сторонний threadedcomments), sitemaps генератор.

А штука вроде deseb, представляющая состояние базы ввиде направленого графа и позволяющего крутить её туда сюда по этому графу в любой момент времени вообще на вес золота.

Почему ругатели джанги про это забывают? Видимо страдают NIH синдромом.

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

>Дизайнеры, которые пишут шаблоны - это утопия.

Бывают и такие ... но обычно с таким же успехом как 0дмины - рисуют :)

>На практике обычно бывает так: пишешь болванку, отдаёшь ему и говоришь: ВСЁ, ЧТО В ФИГУРНЫХ СКОБОЧКАХ - РУКАМИ НЕ ТРОГАТЬ! И то умудряются что-то поломать.

Истинно так! Но вот с джангиными - такое происходит реже. Почему - не знаю - но факт! Впрочем - думаю потому что там не язык, а разметка ... Но я не настаиваю - походу мы с разными дезигнерами работаем :)

GR.

PS: Тем более как я понял - вы уперлись в производительность. Тогда такой пустяк как удобная работа в команде с дезигнерами вас волнует в нн-надцатую очередь - так? У ваших и моих оценок разные веса на критериях - ясен пень №1 вышел разным :)

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

Зопа - огромный страшный тяжеловесный ынтерпрайз-монстр.

> Почему ругатели джанги про это забывают? Видимо страдают NIH синдромом.

NIH-синдром иногда полезен.

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

Скажем так, я за время работы с джангой несколько раз спотыкался об её ограничения и мне надоело.

с большими данными капец. именно из-за этого пришлось на голом цги писать, когда нужно было под железку с 32МБ РАМа наваять вебинтерфейс. yield, кстати, был бы вариантом при выдаче, но абсолютно не спасает от того что заПОСТченный файл передается как переменная, причем копируется дважды

При 32мб рамы питон вообще противопоказан :)

Скажите пожалуйста малоопытному мне,
в каких фреймворках организован html-DOM интерфейс именно такой,
какой в nevow.stan, просто об этом как-то не всегда пишут.

stan преобразует Python-объект в xhtml-код, при этом по умолчанию обрабатываются базовые Python-объекты, также есть набор объектов, изображающих тэги,
а кроме этого поддерживается любой callable и также любой другой объект, реализующий определённый интерфейс.

stan = tags.html[
           tags.body[
               "Hello there", tags.br, "blablabla"
           ]
       ]

Особенно приятно в этом то, что поддерживается визуализация моих собственных объектов, списков , туплей и функций. Считается, что функции возвращают stan.
С объектами и функциями я могу составить динамический xhtml-шаблон на языке питон и без использования HTML-разметки в коде, положить его в переменную и использовать его несколько раз,
каждый раз может генерироваться новое содержимое, не будет меняться только структура.
Самое интересное - у меня всегда будет получаться валидный XHTML.

Капча inlider о чём-то шепчет...

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

Советую узнать о nevow.stan подробнее.
Шаблоны XHTML там реализуются в виде XHTML.
Шаблонизация происходит за счёт атрибутов render и проч.
В render, насколько я помню, задаётся callable, который отвечает за отображение.
Других атрибутов уже не помню, суть в том, что шаблон из XHTML загружается в python-DOM,
получается stan, который потом обрабатывается стандартным способом.

Таким образом, можно из файлов XHTML создавать stan-объекты, а не только наоборот.
Понятно, что верстать такой шаблон можно прямо в любимом десигнерском редакторе,
самое приятное - потом его можно там же перевёрстывать,
причём так, что потом допиливать программерский код в HTML заново не придётся.

Вы лучше скажите, это не модно так делать или какие ещё фреймворки такое позволяют?

ZPT Tal (шаблоны Zope) такое умеет.

>ZPT Tal (шаблоны Zope) такое умеет.

Спасибо, проверю ещё раз, в первый раз не заметил.

Какие ещё?

Zope медленно превращается в религию...

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

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

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

Шаблонизатор не самый быстрый, но очень удобный (mako с этой точки зрения не конкурент). Как вариант, возможно использование jinja (синтаксис похожий кстати).

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

Кстати, забавно, есть весьма интересный проект web2py, но с web.py он имеет мало общего.