blitz templates - теперь на sf.net

fisher

накатила суть
blitz templates - теперь на sf.net

Поскольку сегодня нас проапрувили на sourceforge (http://sourceforge.net/projects/blitz-templates/), я хотел бы сделать первый официальный анонс проекту. До сегодняшнего времени вы, возможно, слышали о blitz templates вскользь в нескольких тредах пхп-клуба, ну и может быть в моем живом журнале - и всё, так что здесь я впервые вкратце попробую рассказать, что это такое и нафига оно нужно. Писать официальные анонсы у меня нет никакого желания, так что простите мне вольности изложения.

Blitz templates изначально задумывался как альтернатива php_templates(http://sourceforge.net/projects/php-templates/). И автор (Максим Полтарак, он же su1d), и многие поклонники этого движка активно тусовались здесь на форуме несколько лет назад, находили баги, предлагали идеи, патчили, писали документацию и так далее. Однако уже несколько лет разработка этого проекта заморожена. Сейчас с выходом новых версий PHP вносятся изменения в код, если он вдруг не собирается, но не более. Несмотря на то, что проект не развивается, php_templates сослужил очень хорошую службу многим девелоперам, проекты росли, росла нагрузка, а это был и остается фактически единственный движок, который можно было спокойно использовать на чуть ли не в любых условиях, особенно не боясь нагрузок. С другой стороны, не всем нравилась аскетичность php_templates, отсутствие объектного API, отсутствие каких-то фич, которым привыкли php-девелоперы, и многие от него стали отказываться в пользу native PHP.

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

В-общем, года полтора назад я решил реанимировать направление php_templates, которое архитектурно мне казалось наиболее правильным - php-модуль, который написан на Си, с внешним API, и шаблонами, где в приниципе невозможно намешать код с HTML так, что увечья детородным органам автору сего безобразия будет самым мягким наказанием, которое придет в голову, если вам придется поддерживать такой код.

Модель, к которой мы пришли в результате экспериментов, основывается на двух частях - view контроллеры (PHP) и шаблоны с минимальной логикой (HTML+). Фактически весь функционал php_templates, плюс "слабая" логика в шаблонах (if, include), и "динамические методы шаблона", суть которых заключается в том, что создавая собственные контроллеры со своими методами разработчик может пользоваться этими методами в тексте шаблона (или отдавать верстальщику API контроллера). В-общем всё вместе получилась довольно замороченная объектная кухня, но на мой взгляд достаточно удобная, масштабируемая, не говоря о том, что работает это очень быстро (бенчмарки в документации). Если интересно посмотреть примеры - сюда, пожалуйста (http://alexeyrybak.com/blitz/blitz_ru.html). Основной упор сделан на то, что в будущем мы столнемся с интернет-приложениями совершенно нового типа - это будут просто полноценные приложения, по сложности интерфейсов они вряд ли будут отличаться от современных десктопных. И view-часть этих приложений это уже никак не простейшие кусочки с циклами и echo, которые ты делаешь на автомате пиша пхп-скрипты, а всё в месте это действительно довольно громоздкий код сам по себе, в котором должен быть порядок.

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

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

desperado

Новичок
ну, если только в мане во второй часте, в третьей главе make и ./configure местами поменять
 

Alexandre

PHPПенсионер
Алексей, Поздравляю с реализацией.
Я давно слежу за развитием событий и буду твой движок использовать в одном из больших проектов.
 

fisher

накатила суть
v. 0.4.4
Lower/upper case policy was changed. Varible and context names are case sensitive, while method names are not. A feature for commonly used context format compatibility was added: <!-- BEGIN ctx --> ... <!-- END ctx -->. Other minor fixes were made.

также думаю будет любопытны новая диаграмма тестирования по моей методике, куда на данный момент включены smarty, php_templates, sigma, FastTemplate, XTemplate, native php и blitz.
http://alexeyrybak.com/blitz/lebowski-bench-big.gif

-~{}~ 01.03.07 11:39:

v 0.4.6
An internal output wrapper was added: escape. {{ escape($a); }}, works exactly like <? echo htmlspecialchars($a, ENT_QUOTES); ?>. Minor fixes were made for tests and documentation. A syntax warning for HTML comments in alternative context format mode (<!-- BEGIN ctx --> ... <!-- END ctx -->) was fixed.
 

dark-demon

d(^-^)b
если не сложно, сравни ещё и с моим "движком": http://pastebin.mozilla-russia.org/859

по идее должно быть на уровне инклудов или отставать, но вот на сколько...

а кто такой ZPS?
 

fisher

накатила суть
у меня банально нет времени добавлять тесты для всех движков. есть разумная альтернатива - скачиваешь бенчмарк (http://alexeyrybak.com/blitz/lebowski_bench.tar.gz), пишешь свой тест, присылаешь мне, я запускаю.

-~{}~ 01.03.07 17:40:

так, стоп, я забыл написать - если это действительно движок. то что я вижу по ссылке - это не шаблонный движок.

-~{}~ 01.03.07 17:40:

ZPS - zend performance suite
 

dark-demon

d(^-^)b
у меня банально нет времени добавлять тесты для всех движков. есть разумная альтернатива - скачиваешь бенчмарк (http://alexeyrybak.com/blitz/lebowski_bench.tar.gz), пишешь свой тест, присылаешь мне, я запускаю.
дык у тебя уже всё написано... шаблоны можно пользовать те же, что и в случае с инклудами (с небольшой правкой).

так, стоп, я забыл написать - если это действительно движок. то что я вижу по ссылке - это не шаблонный движок.
а движок должен быть оформлен ввиде монстрокласса? =) темплейты для этого движка - обычные PHP файлы, которые принимают данные через переменную $var, а отдают обычным способом.
 

fisher

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

Krishna

Продался Java
fisher
А чем объясняется проигрыш в производительности откомпилированного Смарти? eval()?
 

Фанат

oncle terrible
Команда форума
Krishna
Я недавно задавал вопрос о производительности смарти. там дали много ответов, которые можно использовать, как пищу для размышлений.
Задавать же этот вопрос автору blitz, как минимум - нелогично
 

Krishna

Продался Java
Фанат
Я думаю, что fisher значительно больше "в теме", чем большинство потенциальных отвечателей этого форума.
По-этому, на мой взгляд, вполне логично.
 

Фанат

oncle terrible
Команда форума
fisher значительно больше "в теме", чем большинство потенциальных отвечателей этого форума по весьма обширному кругу веб-технологий. давай зававать ему вопросы на этом основании в теме про blitz.
здесь, если ты не понял, обсуждается шаблонизатор. и он называется не смарти.

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

Krishna

Продался Java
Возможно, я неправильно задал вопрос.
Меня мало интересует Смарти (как и большинство PHP4 совместимых, устаревших продуктов)

Меня как раз интересует blitz
А точнее - мне интересно, чем вызваны бонусы производительности blitz, относительно, как я понимаю любого шаблонизатора с компилируемыми шаблонами. Исключительно "загроможденностью" генерированного кода?
Правильно ли я понял, что blitz шаблоны быстрее не только за счет более высокой скорости трансляции шаблонов?

И, туда же, до кучи, а чем будет вызвано преимущество blitz, перед простыми XSLT-шаблонами, ведь там, насколько мне известно (тут я не в теме, нет опыта работы с XSLT) в качестве транслятора будет выступать модуль, написанный на Си?

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

dark-demon

d(^-^)b
Тема мне интересна, я сам часто задавался вопросом, почему в пхп нет стандартного модуля-шаблонизатора.
потому, что пхп - это и есть шаблонизатор :) просто очень продвинутый...

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

fisher

накатила суть
Krishna - я не занимаюсь пеаром и продажами. Есть вещи которые кажутся удобными и нужными мне - я ими делюсь. Задачи разобраться во всём, найти четкие причины и объяснения - интересная но очень сложная, поэтому я просто делаю тесты и измеряю. И никого ни на что особенно не агитирую. То, что я пишу сюда (то есть вот конкретно в этот тред) носит только две цели - если просто интересно - то заставить думать, если используете blitz - то анонсы + помощь в улучшении.

>>относительно, как я понимаю любого
>>шаблонизатора с компилируемыми шаблонами

я этого не говорил. я говорил, что не вижу сейчас решения для нагруженного проекта, построенного по этой модели. с мной на днях связался один из разработчиков он сделал для пхп экстеншн ctemplates от Гугла. Это ещё один c-based шаблонизатор, который я не мерял, есть ещё от ребят из мейл.ру - вот в ближайшее время я всё это добавлю в тесты (что отдельно интересно, они оба даже Cи++ а не Cи). И просто измерю. И что-то мне подсказывает что именно C-based шаблонизаторы должны составить авангард по скорости. Ещё раз - я просто придумываю более-менее адекватный метод измерения, меряю и говорю, ребята, смотрите, есть над чем думать. Моя задача - просто выбирать наиболее эффективные решения. Если я найду что-то лучше - я возьму его. Интересно вам про XSLT - возмите задачу, реализуйте её в рескольких альтернативных вариантах и выберите решение. Возмите например мой бенчмарк, сделпайте тест - я могу его замеритью. Щас я понятия не имею, насколько это будет медленнее.

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

Фанат прав - если хотите поговорить на общие темы - лучше поднимать тот старый тред или создавать новый.

>>интересно, что php mess рвёт всех как тузик грелку... даже компилленный смарти...
Я вообще боялся, когда думал что включать в тесты - что первое вот это впечатление сразу даст аткой сигнальчег - а прекрасно какой клёвый оказывается сам внутри PHP. Обратите внимание - что такое PHP mess- там нет ни одного инклюда, вообще. Это и есть сферический конь. У PHP тупят именно инклюды. А множество инклюдов будет в сложном view-коде просто потому что они навязаны "плоской" шаблонной моделью PHP.
 

Develar

Новичок
>> У PHP тупят именно инклюды
>> они навязаны "плоской" шаблонной моделью PHP
Сам blitz волшебным образом не избавляет от этих тормозов, он позволяет от них отказаться используя контексты. То есть мы должны стремиться запихать как можно больше кода в один файл?
... и этот большой кусок кода не будет рвать нам голову за счет грамотно спроектированного языка blitz.
 

fisher

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

Develar

Новичок
А куда писать о FR? Пока что написал на http://alexeyrybak.com/blitz/bt, но вы ведь на sf открыли проект, должно быть некое единство, а то и статистика скачивания неверная, то с sf, то с alexeyrybak.com.
 

fisher

накатила суть
всё правильно - в мантис на старом сайте. request интересный, подумаю.
 
Сверху