Я бы немного почетче сформулировал.
В контексте данного обсуждения под PHP mess подразумевается не отсутствие шаблонов вообще, а шаблон на чистом PHP без отдельного шаблонизатора.
Занимается, насколько мне известно.
Можно даже ему написать о проблемах. Вот только в силу уже упомянутой молодости реагирует он не всегда адекватно, что жаль. Хотя тот же самый фактор может его заставить немедленно исправить ошибку =)
Ссылку на релиз я брал отсюда: http://phpclub.ru/talk/showthread.php?s=…
Можно, наверное, ему туда написать
А подо что оно отжирает память? Насколько я понимаю, может жрать только при компиляции? Или на чем-то ещё?
Усложнением интаксиса, наверное.
Тема, кстати, важная и интересная. Достойная, на мой взгляд, отдельного обсуждения. Вот все говорят - PHP-native, но подходы-то ведь у всех наверняка разные! Слишком большой язык. Слишком велик соблазн скатиться к той же лапше, от которой хотели уйти.
Мой подход - сознательное ограничение используемого в шаблонах синтаксиса. Жёсткое. В частности, $var= <<<HTML... мне, признаюсь, в страшном сне не приснится.
Мне предлагали функцию сделать. Это тоже представляется неподходящим для шаблона. Как и строковые замены с последующим eval-ом вместо инклюда.
А другие способы организовать блок мне не приходят в голову.
Слушай, ты перевернул все мои представления о разделении труда верстальщика и программиста =) А можно хоть чуть-чуть поподробнее про это?
Почему подход "я все данные посЕтил" плохой? Речь идет о том самом облегчении труда верстальщика, который, в отличие от яндексовых верстал, совсем не морочится с логикой, а только чисто с хтмл/цсс?
Поскольку проект - плод одного, хоть и весьма талантливого энтузиаста, да к тому же ещё и совсем юного, то сайта у него нет, есть только линк на релиз: http://vsudebyl.cz/files/quicky_0.3.03.r…
Точку зрения автора можно почитать в docs/story.txt
Увы,я не пользуюсь Блицем, мой выбор - PHP-native =)
Я исхожу из общих представлений о шаблонизаторах его семейства. Выделяется блок, и скрипт-обработчик рекурсивно обходит данные, заполняя его. В самом простом варианте - корректно открывая и закрывая <ul>
А вот кстати. Вопрос по взаимодействию верстальщика и программиста. Как решается классическая засада, когда в скрипте программер не знает, что такое READ_MORE - его в цикле итерировать или проверять на наличие данных?
Какой-то есть формальный протокол согласования, или просто работают в живом контакте?
Подставь в свой текст слово Смарти вместо Блиц - совпадет на 100% =)
На смарти тоже есть проекты, где одни контексты. И летает оно прекрасно, поскольку по сути php mess...
Собственно, наличие Смарти и заставляет так думать. Ну, и постепенное движение Блица от "блочного" классического шаблонизатора к "логическому".
Хотя, возможно, я и на пустом месте переживаю.
И, тем не менее, шаблон у "блочного" шаблонизатора (к которым относится Блиц) по определению всегда будет выглядить проще. За счет того, что на самом деле он состоит из двух частей - собственно шаблона и скрипта-обработчика. Как пример могу привести то же самое дерево: выделяем строчку HTML в блок и обрабатываем его рекурсивно. В "логическом" же шаблонизаторе дерево - pain in the..., скажем, head.
Классическая задача - вывести небольшое дерево. Карту сайта или, скажем, меню с подменю одного уровня. С выделением текущего раздела. HTML кода будет меньше, чем PHP (или любого другого, при использовании любого шаблонизатора)
Есть ли четкая политика, которая ограничивает выполнение реквестов? Не "доходом рук", а по принципиальным соображениям. Очень боюсь, что Блиц превратится в Смарти N2 и "теперь мы попробуем со всей этой фигней взлететь"
Функционал в смарти слишком перегружен, имхо. В разы. Не редкость хелперы, которые напрямую работают с БД. Ушли от PHP... "и вышли таки обратно на Дерибасовскую" - получили ту же самую лапшу. Только утяжелённую.
Появление таких проектов, как Smarty Lite, Quicky - говорит само за себя.
В контексте данного обсуждения под PHP mess подразумевается не отсутствие шаблонов вообще, а шаблон на чистом PHP без отдельного шаблонизатора.
Можно даже ему написать о проблемах. Вот только в силу уже упомянутой молодости реагирует он не всегда адекватно, что жаль. Хотя тот же самый фактор может его заставить немедленно исправить ошибку =)
Ссылку на релиз я брал отсюда:
http://phpclub.ru/talk/showthread.php?s=…
Можно, наверное, ему туда написать
А подо что оно отжирает память? Насколько я понимаю, может жрать только при компиляции? Или на чем-то ещё?
Тема, кстати, важная и интересная. Достойная, на мой взгляд, отдельного обсуждения. Вот все говорят - PHP-native, но подходы-то ведь у всех наверняка разные! Слишком большой язык. Слишком велик соблазн скатиться к той же лапше, от которой хотели уйти.
Мой подход - сознательное ограничение используемого в шаблонах синтаксиса. Жёсткое. В частности, $var= <<<HTML... мне, признаюсь, в страшном сне не приснится.
Мне предлагали функцию сделать. Это тоже представляется неподходящим для шаблона. Как и строковые замены с последующим eval-ом вместо инклюда.
А другие способы организовать блок мне не приходят в голову.
Почему подход "я все данные посЕтил" плохой? Речь идет о том самом облегчении труда верстальщика, который, в отличие от яндексовых верстал, совсем не морочится с логикой, а только чисто с хтмл/цсс?
Точку зрения автора можно почитать в docs/story.txt
Я исхожу из общих представлений о шаблонизаторах его семейства. Выделяется блок, и скрипт-обработчик рекурсивно обходит данные, заполняя его. В самом простом варианте - корректно открывая и закрывая <ul>
Какой-то есть формальный протокол согласования, или просто работают в живом контакте?
На смарти тоже есть проекты, где одни контексты. И летает оно прекрасно, поскольку по сути php mess...
Собственно, наличие Смарти и заставляет так думать. Ну, и постепенное движение Блица от "блочного" классического шаблонизатора к "логическому".
Хотя, возможно, я и на пустом месте переживаю.
Появление таких проектов, как Smarty Lite, Quicky - говорит само за себя.