В идее есть очевидная кривизна, которая сводит её всю на нет.
Во-первых, дурацкое ограничение на использование ссылки - только рассылка по e-mail. И это пишется на блог-хостинге!
Во-вторых, полное отсутствие контроля после первого же хопа. Следующий получатель уже ни за что не отвечает и публикует в блоге.
Получается, что доверенный юзер
а) Должен сопровождать ссылку комментарием "только никому её не давай - это секретная ссылка!", что вызовет вопросов больше, чем тема публикации.
б) после первого же наказания ни за что справедливо рассудит, "на кой бес мне этот стресс" и станет давать нормальные обычные ссылки.
Плюс, как говорится, адин.
Это первое, что бросается в глаза при прочтении - по нынешним временам цифра нереально маленькая.
Дальше какие-то странные рассуждения про ловлю преступников со спины. Какие там парметры могут быть? Цвет? Форма? При разрешении камер - ну, даже если 1900 точек, на спину придется максимум сотня. Этак половину прохожих можно будет забирать сразу.
Рискну, всё же, возразить.
Дело в том, что для блочного шаблонизатора конструкция
{{BEGIN name}}{{END}} - стандартная сущность. Для PHP native же это добавление новой.
В этом ведь и состоит, на мой взгляд, главная привлекательность "блочных" шаблонов - предельная простота синтаксиса. Блоки да переменные - больше ничего и не надо.
Именно таких случаев я и боюсь, когда для каждой новой задачи в шаблон вносится новый синтаксический элемент, и в результате - ...
Круто. Спасибо, это очень интересная информация с совершенно неизвестной мне стороны.
А вот такой вопрос ещё, если можно. Отделяется ли у вас организационно этот контроллер от мотороллера шаблона? Или органично лежит в остальном коде? Теоретически - должно разделяться, но интересует именно опять ваш практический опыт =)
Я бы немного почетче сформулировал.
В контексте данного обсуждения под 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 - говорит само за себя.
Во-первых, дурацкое ограничение на использование ссылки - только рассылка по e-mail. И это пишется на блог-хостинге!
Во-вторых, полное отсутствие контроля после первого же хопа. Следующий получатель уже ни за что не отвечает и публикует в блоге.
Получается, что доверенный юзер
а) Должен сопровождать ссылку комментарием "только никому её не давай - это секретная ссылка!", что вызовет вопросов больше, чем тема публикации.
б) после первого же наказания ни за что справедливо рассудит, "на кой бес мне этот стресс" и станет давать нормальные обычные ссылки.
Это первое, что бросается в глаза при прочтении - по нынешним временам цифра нереально маленькая.
Дальше какие-то странные рассуждения про ловлю преступников со спины. Какие там парметры могут быть? Цвет? Форма? При разрешении камер - ну, даже если 1900 точек, на спину придется максимум сотня. Этак половину прохожих можно будет забирать сразу.
Дело в том, что для блочного шаблонизатора конструкция
{{BEGIN name}}{{END}} - стандартная сущность. Для PHP native же это добавление новой.
В этом ведь и состоит, на мой взгляд, главная привлекательность "блочных" шаблонов - предельная простота синтаксиса. Блоки да переменные - больше ничего и не надо.
Именно таких случаев я и боюсь, когда для каждой новой задачи в шаблон вносится новый синтаксический элемент, и в результате - ...
А вот такой вопрос ещё, если можно. Отделяется ли у вас организационно этот контроллер
от мотороллерашаблона? Или органично лежит в остальном коде? Теоретически - должно разделяться, но интересует именно опять ваш практический опыт =)В контексте данного обсуждения под PHP mess подразумевается не отсутствие шаблонов вообще, а шаблон на чистом PHP без отдельного шаблонизатора.
Можно даже ему написать о проблемах. Вот только в силу уже упомянутой молодости реагирует он не всегда адекватно, что жаль. Хотя тот же самый фактор может его заставить немедленно исправить ошибку =)
Ссылку на релиз я брал отсюда:
http://phpclub.ru/talk/showthread.php?s=…
Можно, наверное, ему туда написать
А подо что оно отжирает память? Насколько я понимаю, может жрать только при компиляции? Или на чем-то ещё?
Тема, кстати, важная и интересная. Достойная, на мой взгляд, отдельного обсуждения. Вот все говорят - PHP-native, но подходы-то ведь у всех наверняка разные! Слишком большой язык. Слишком велик соблазн скатиться к той же лапше, от которой хотели уйти.
Мой подход - сознательное ограничение используемого в шаблонах синтаксиса. Жёсткое. В частности, $var= <<<HTML... мне, признаюсь, в страшном сне не приснится.
Мне предлагали функцию сделать. Это тоже представляется неподходящим для шаблона. Как и строковые замены с последующим eval-ом вместо инклюда.
А другие способы организовать блок мне не приходят в голову.
Почему подход "я все данные посЕтил" плохой? Речь идет о том самом облегчении труда верстальщика, который, в отличие от яндексовых верстал, совсем не морочится с логикой, а только чисто с хтмл/цсс?
Точку зрения автора можно почитать в docs/story.txt
Я исхожу из общих представлений о шаблонизаторах его семейства. Выделяется блок, и скрипт-обработчик рекурсивно обходит данные, заполняя его. В самом простом варианте - корректно открывая и закрывая <ul>
Какой-то есть формальный протокол согласования, или просто работают в живом контакте?
На смарти тоже есть проекты, где одни контексты. И летает оно прекрасно, поскольку по сути php mess...
Собственно, наличие Смарти и заставляет так думать. Ну, и постепенное движение Блица от "блочного" классического шаблонизатора к "логическому".
Хотя, возможно, я и на пустом месте переживаю.
Появление таких проектов, как Smarty Lite, Quicky - говорит само за себя.