Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 239
Заинтересованность шаблонизаторами на Хабре набирает обороты =)
>Quicky быстрее PHP-native?
>Невероятно, но факт: квики может быть быстрее.
>Во всех примерах в конечный шаблон падут результаты работы этих операторов, тоесть фактически _ перед выражением означает eval() при компиляции
Если eval() то это уже точно не быстрее… Как минимум так же… но не быстрее =))
>Невероятно, но факт: квики может быть быстрее.
>Во всех примерах в конечный шаблон падут результаты работы этих операторов, тоесть фактически _ перед выражением означает eval() при компиляции
Если eval() то это уже точно не быстрее… Как минимум так же… но не быстрее =))
eval() вызывается только при компиляции шаблона — поэтому и быстрее :)
поясню еще раз:
возможно у вас в шаблоне есть какое-либо выражение которое при повтороной генерации вывода будет давать вточности такое же значение, тогда вам достаточно расчитать его один раз при компиляции — на это указывает "_" перед выражением.
возможно у вас в шаблоне есть какое-либо выражение которое при повтороной генерации вывода будет давать вточности такое же значение, тогда вам достаточно расчитать его один раз при компиляции — на это указывает "_" перед выражением.
Ой…
Самый быстрый шаблонизатор — это PHP-native, зачем же говорить, что некий шаблонизатор с кэшированием в статический HTML быстрее PHP-native? Давайте же и сравнивать PHP-native шаблонизатор + кэширование и Х-шаблонизатор + кэширование
Самый быстрый шаблонизатор — это PHP-native, зачем же говорить, что некий шаблонизатор с кэшированием в статический HTML быстрее PHP-native? Давайте же и сравнивать PHP-native шаблонизатор + кэширование и Х-шаблонизатор + кэширование
И удобный ;)
Это опять конечно же холивар. Кому как удобно пусть так и работает, конечно же. Но зачем юзеру опять «учить» новый шаблонизатор, фактически «язык» учить?
Один раз выучил основы php (foreach и как выводить данные — этого достаточно) — и хватит с головой и на долго.
Просто надо сразу делать правильную архитектуру проекта. А не извращаться потом в шаблонизаторах.
Это опять конечно же холивар. Кому как удобно пусть так и работает, конечно же. Но зачем юзеру опять «учить» новый шаблонизатор, фактически «язык» учить?
Один раз выучил основы php (foreach и как выводить данные — этого достаточно) — и хватит с головой и на долго.
Просто надо сразу делать правильную архитектуру проекта. А не извращаться потом в шаблонизаторах.
Я за :)
Почему я не люблю смарти, и уже не нравится квики:
Создатели боролись-боролись с разделением и повышением гибкости что поборолись до того с чем боролись.
1) Что бы научится что то вывести на экран нужно кучу геморроя пройти.
2) разделяли-разделяли да переразделили, теперь не в PHP выводим HTML, а в HTML — PHP, ы прикольно…
3) на основе пункта 2 мы так и не избавились от зависимости дизайнера от программиста и наоборот, а еще и увеличили…
Сугубо мое мнение, сильно не пинайте, просто накипело ;)
Почему я не люблю смарти, и уже не нравится квики:
Создатели боролись-боролись с разделением и повышением гибкости что поборолись до того с чем боролись.
1) Что бы научится что то вывести на экран нужно кучу геморроя пройти.
2) разделяли-разделяли да переразделили, теперь не в PHP выводим HTML, а в HTML — PHP, ы прикольно…
3) на основе пункта 2 мы так и не избавились от зависимости дизайнера от программиста и наоборот, а еще и увеличили…
Сугубо мое мнение, сильно не пинайте, просто накипело ;)
Священная война идет тут:
developer.habrahabr.ru/blog/45370/
developer.habrahabr.ru/blog/45370/
>Один раз выучил основы
Это подход, недостойный программиста.
Это подход, недостойный программиста.
Это не для программиста :))
Это для дизайнера, простого пользователя.
Это для дизайнера, простого пользователя.
А для дизайнра — PHP — это уже оверкилл :)
Я же и написал — основы.
При грамотной реализации архитектуры всего-то знать то надо будет, как работает foreach и if(), а также echo или print.
C этим справится не только дизайнер, но и любой школьник.
При грамотной реализации архитектуры всего-то знать то надо будет, как работает foreach и if(), а также echo или print.
C этим справится не только дизайнер, но и любой школьник.
Ага, и про htmplscecialchars() расскажете, и про массивы, объекты и прочая? Верстальщика то не жалко?
А Quicky — да слоднее, но не для чайников. Завто есть свои преимущества.
А Quicky — да слоднее, но не для чайников. Завто есть свои преимущества.
Хорош халиварить.
При чем здесь htmplscecialchars()? Все «вопросы» безопастности (и не только) вы должны решить до «вывода» контента.
Если вы осталвляете верстальшику htmplscecialchars то у вас или «никакая» архитектура или проблемы с безопастностью.
На view — должен передаваться только один массив «подготовленных» данных и всё, если не так то у вас проблема с MVC.
При чем здесь htmplscecialchars()? Все «вопросы» безопастности (и не только) вы должны решить до «вывода» контента.
Если вы осталвляете верстальшику htmplscecialchars то у вас или «никакая» архитектура или проблемы с безопастностью.
На view — должен передаваться только один массив «подготовленных» данных и всё, если не так то у вас проблема с MVC.
> Все «вопросы» безопастности (и не только) вы должны решить до «вывода» контента.
А вот и нет) Этим должен заниматься шблонизатор, делать мне больше нечего, по всем данным делать htmlspecialchars()
> На view — должен передаваться только один массив «подготовленных» данных и всё, если не так то у вас проблема с MVC.
Мда… мне на это даже сказать нечего… где же по вашему должны обрабатываться эти данные (тот самый specialchars(), форматирование цифр, даты, склонение слов (типа «3 комментария»)), ответь-те ка (вопрос с подвохом)))?
А вот и нет) Этим должен заниматься шблонизатор, делать мне больше нечего, по всем данным делать htmlspecialchars()
> На view — должен передаваться только один массив «подготовленных» данных и всё, если не так то у вас проблема с MVC.
Мда… мне на это даже сказать нечего… где же по вашему должны обрабатываться эти данные (тот самый specialchars(), форматирование цифр, даты, склонение слов (типа «3 комментария»)), ответь-те ка (вопрос с подвохом)))?
вы знаете, там много всего, так сказать нельзя однозначно.
вот, например, я считаю, что программист должен указывать которые данные опасны к выводу а какие нет (потому что тока он и знает), а вот верстальщик не должен. Но я знаю что много людей думает не так и у них свои аргументы и от некоторых я не могу отмахнуться до сих пор =) самый прикольный звучит так: 90% шаблонов «дотачивается» программистами. Если это правда, то какая разница чем пользоваться? только вопрос удобства остается и личных предпочтений. Лично я просто привык мыслить в масштабе на команду 3 и выше людей.
вот, например, я считаю, что программист должен указывать которые данные опасны к выводу а какие нет (потому что тока он и знает), а вот верстальщик не должен. Но я знаю что много людей думает не так и у них свои аргументы и от некоторых я не могу отмахнуться до сих пор =) самый прикольный звучит так: 90% шаблонов «дотачивается» программистами. Если это правда, то какая разница чем пользоваться? только вопрос удобства остается и личных предпочтений. Лично я просто привык мыслить в масштабе на команду 3 и выше людей.
> что программист должен указывать которые данные опасны к выводу а какие нет (потому что тока он и знает), а вот верстальщик не должен.
Согласен, тут получается проблемка… но вручную в контроллере в цикле обрабатывать данные — это как минимум, монотонно и надоест, да и архитектура страдает.
Единственныей выход, который я вижу — передавать в шаблон мета-информацию о типе данных, то етсь верстальщик пишет {$title}, а шаблонизатор смотрт по заданным прогаммистом правилам — как выодить этот title. В простейшем случае эту инфу можно передавть в масиве: $dataTypes['title'] = 'HTML', или прикручивать к шаблону файл с правилами, почему бы и нет, зато при смене шаблона его не надо будет трогать программисту.
Согласен, тут получается проблемка… но вручную в контроллере в цикле обрабатывать данные — это как минимум, монотонно и надоест, да и архитектура страдает.
Единственныей выход, который я вижу — передавать в шаблон мета-информацию о типе данных, то етсь верстальщик пишет {$title}, а шаблонизатор смотрт по заданным прогаммистом правилам — как выодить этот title. В простейшем случае эту инфу можно передавть в масиве: $dataTypes['title'] = 'HTML', или прикручивать к шаблону файл с правилами, почему бы и нет, зато при смене шаблона его не надо будет трогать программисту.
я делаю так
$tpl->assign($name,$value, $escape=true);
$tpl->assign($name,$value, $escape=true);
Да, я уже на Хабре видел такую конструкцию, и мне она не понравилась, ибо фейл получается при передаче массива, где допустим title надо ескейпить, а content нет (а я с этим постоянно сталкивался). а если массив 2 мерный?
ААААААААА.
Спасибо.
А то утомило stripslashes в каждом файле подключать как функцию Smarty… :(
Спасибо.
А то утомило stripslashes в каждом файле подключать как функцию Smarty… :(
Молодой человек, вы наверно не поняли.
Данные «подготавливаются» в модулях и ядре (которые обмениваются данными посредством контроллера) и контроллером отправляются на view (когда готовы). Так вот модель view это уже фактически и есть обработка данных шаблонизатором (любым, хоть самим php). Так вот, данные должны уже быть и защищены, и обработаны, иначе у вас архитектура не соотвествует MVC.
Данные «подготавливаются» в модулях и ядре (которые обмениваются данными посредством контроллера) и контроллером отправляются на view (когда готовы). Так вот модель view это уже фактически и есть обработка данных шаблонизатором (любым, хоть самим php). Так вот, данные должны уже быть и защищены, и обработаны, иначе у вас архитектура не соотвествует MVC.
конкретно вопрос: Защита от XSS лежит на модели, вьювере или контроллере?
Напомню немного о MVC.
Шаблон MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента
Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контролера ), изменяя свое состояние.
Представление (View). Отвечает за отображение информации (пользовательский интерфейс).
Поведение (Controller). Интерпретирует данные, введенные пользователем, и информирует модель и представление о необходимости соответствующей реакции.
Поэтому :) не во вьюере :)
Вообще идеально — в модели. Контроллер — это своего рода триггер, перенаправляющий данные в зависимости от поступающих на управление в него данных.
А все вычисления и обработка данных должны делаться в модели.
Важно отметить, что как представление, так и поведение зависят от модели. Однако модель не зависит ни от представления, ни от поведения. Это одно из ключевых достоинств подобного разделения. Оно позволяет строить модель независимо от визуального представления, а также создавать несколько различных представлений для одной модели.
Шаблон MVC позволяет разделить данные, представление и обработку действий пользователя на три отдельных компонента
Модель (Model). Модель предоставляет данные (обычно для View), а также реагирует на запросы (обычно от контролера ), изменяя свое состояние.
Представление (View). Отвечает за отображение информации (пользовательский интерфейс).
Поведение (Controller). Интерпретирует данные, введенные пользователем, и информирует модель и представление о необходимости соответствующей реакции.
Поэтому :) не во вьюере :)
Вообще идеально — в модели. Контроллер — это своего рода триггер, перенаправляющий данные в зависимости от поступающих на управление в него данных.
А все вычисления и обработка данных должны делаться в модели.
Важно отметить, что как представление, так и поведение зависят от модели. Однако модель не зависит ни от представления, ни от поведения. Это одно из ключевых достоинств подобного разделения. Оно позволяет строить модель независимо от визуального представления, а также создавать несколько различных представлений для одной модели.
> Вообще идеально — в модели.
Да да да) Хлеба и зрелищ! Сделайте аналог htmlspecialchars функцией MySQL ))) Вот смеху будет.
Да да да) Хлеба и зрелищ! Сделайте аналог htmlspecialchars функцией MySQL ))) Вот смеху будет.
оставил кота, ушел из этой ветки диалога.
Причем здесь это? При чем здесь аналог? Что за бред вы несете.
Да обработайте данные в модели своим htmlspecialchars на здоровье или вообще своим модулем.
Вы наверно плохо представляете MVC. Я не удивляюсь потом ошибкам в архитектурах, да вообще, кто то делает архитектуру? Дай бог что многие уже начали писать код при помощи fw. И на том спасибо.
И то считают fw — архитектурой :) Напомню это — инструмент.
Да обработайте данные в модели своим htmlspecialchars на здоровье или вообще своим модулем.
Вы наверно плохо представляете MVC. Я не удивляюсь потом ошибкам в архитектурах, да вообще, кто то делает архитектуру? Дай бог что многие уже начали писать код при помощи fw. И на том спасибо.
И то считают fw — архитектурой :) Напомню это — инструмент.
Меня всегда улыбало слово «защита» в подобном контексте. Это не защита, а часть логики представления данных согласно правилам XHTML (XML). Это всё равно что экранирование спец. символов в строках участвующих в составлении SQL-называть защитой от SQL-инъекции и гонять через antihacker().
К информационной защите относится шифрование, защита от DDoS и т.д.
Если понадобится выводить данные не в HTML, а в plaintext например — менять бизнес-логику? Кстати, преобразовывать спец. символы XHTML в мнемонические последовательности нужно далеко не во всех переменных.
> и обработаны,
А это вообще отдает ламерством. Когда верстальщику надо будет обрезать новость до 150 символов, а не до 151 — буду насиловать мозг программисту. Хотя это воплощение логики ПРЕДСТАВЛЕНИЯ.
К информационной защите относится шифрование, защита от DDoS и т.д.
Если понадобится выводить данные не в HTML, а в plaintext например — менять бизнес-логику? Кстати, преобразовывать спец. символы XHTML в мнемонические последовательности нужно далеко не во всех переменных.
> и обработаны,
А это вообще отдает ламерством. Когда верстальщику надо будет обрезать новость до 150 символов, а не до 151 — буду насиловать мозг программисту. Хотя это воплощение логики ПРЕДСТАВЛЕНИЯ.
Я промолчу по поводу ламеризма. Мне например попахивает ламеризмом от шаблонизаторов имхо.
Вы судите как программист, но не как инженер.
Спросите у верстальщиков про шаблонизаторы. Вы услышите кучу матов в их сторону.
То смарти, то квики. то еще какая нибудь фигня. И все это надо учить по новой верстальщикам, приходят в одну контору — смарти, в другую — еще что-то, в третьей — третье. И самое интересное везде разная логика.
Я понимаю, кто как хочет так и выводит данные. Но не надо засорять другой логикой, в которой ВЫ думаете что это правильно. Чем попахивает?
И причем здесь безопастность и view?
Вы судите как программист, но не как инженер.
Спросите у верстальщиков про шаблонизаторы. Вы услышите кучу матов в их сторону.
То смарти, то квики. то еще какая нибудь фигня. И все это надо учить по новой верстальщикам, приходят в одну контору — смарти, в другую — еще что-то, в третьей — третье. И самое интересное везде разная логика.
Я понимаю, кто как хочет так и выводит данные. Но не надо засорять другой логикой, в которой ВЫ думаете что это правильно. Чем попахивает?
И причем здесь безопастность и view?
квик работает на основе синтаксиса смарти. Видно что вы не прочитали статью — диалог не конструктивен. Вы говорите ни о чем. Как можно спорить о том, о чем вы в общем-то не удостоились прочитать?
Значит это не верстальщики. К примеру наши верстальщики положительно относятся к шаблонизаторам, которые дают инструментарий по модификации данных и логике.
> приходят в одну контору — смарти, в другую — еще что-то, в третьей — третье. И самое интересное везде разная логика.
Чтобы выучить Quicky на уровне верстки нужен час. Это не так много если планируешь работать хотя бы месяц.
> приходят в одну контору — смарти, в другую — еще что-то, в третьей — третье. И самое интересное везде разная логика.
Чтобы выучить Quicky на уровне верстки нужен час. Это не так много если планируешь работать хотя бы месяц.
Чтобы выучить основы php тоже нужет час. У меня сын в 12 лет за 1 час понял все основы. Хотя ничем таким до этого кроме уроков информатики не посещал.
Ответьте на один вопрос, почему разработчики php отказались от поставки в php smarty, хотя поначалу планироваль? Мало того потом резко измениль курс в обратную сторону. Найдете сами?
Ответьте на один вопрос, почему разработчики php отказались от поставки в php smarty, хотя поначалу планироваль? Мало того потом резко измениль курс в обратную сторону. Найдете сами?
вы будите всех верстальщиков учить что везде нужно расставлять эскейпы и объяснять им что эти данные представляют потенциальную угрозу?
Это хак, потому что комплексного решения проблемы нет, предложите комплексное решение.
Это хак, потому что комплексного решения проблемы нет, предложите комплексное решение.
Не везде, а где это требуется. Если верстальщик берется за реализацию логики представления (написание шаблона) — его алгоритм должен генерировать XHTML без неочевидного поведения.
Верстальщик понятия не должен иметь о «безопастности».
Это должно быть заложено в архитектуре проекта.
Это должно быть заложено в архитектуре проекта.
Тогда выход, чтобы не нарушать идею MVC только один — к кадждому шаблону прикладывать файл (который тоже будет фактически частью View), с описанием типов данных. Этот файл доверить программисту.
Интересно, а как с форматированием допустим дат, вы их в контроллере форматируете? А склонение слов?
Интересно, а как с форматированием допустим дат, вы их в контроллере форматируете? А склонение слов?
То есть вы отправляете уже преобразованные в HTML данные во View и искренне считаете, что это и есть MVC?
Хорошо, вопрос тогда такой)) Неожиданно оказалось, что нужно обеспечить работу вашего чудо-проекта в командной строке)) Соответственно вывод идет в консоль. Внимание, вопрос: что вы будете делать с вашими HTML-данными?
1) Преобразовывать назад в plain-text — а какой смысл в двойном преобразовании туда-обратно?
2) лазить по коду и убирать вызов htmlscpecialchars()?
В нормальном MVC достаточно было бы поменять View, поставив скажем вместо HTML_View CommandLine_View, а как у вас?
Если вам не нравится пример с командной строкой, возьмите пример экспорта в ПДФ или txt.
В MVC, к вашему сведению, Модель (М), подготавливает данные (не зная, куда они дальше будут направлены), а View(V) выводит в *требуемом* формате, и HTML — только один из множества возможных. Что ж тут непонятного?
Хорошо, вопрос тогда такой)) Неожиданно оказалось, что нужно обеспечить работу вашего чудо-проекта в командной строке)) Соответственно вывод идет в консоль. Внимание, вопрос: что вы будете делать с вашими HTML-данными?
1) Преобразовывать назад в plain-text — а какой смысл в двойном преобразовании туда-обратно?
2) лазить по коду и убирать вызов htmlscpecialchars()?
В нормальном MVC достаточно было бы поменять View, поставив скажем вместо HTML_View CommandLine_View, а как у вас?
Если вам не нравится пример с командной строкой, возьмите пример экспорта в ПДФ или txt.
В MVC, к вашему сведению, Модель (М), подготавливает данные (не зная, куда они дальше будут направлены), а View(V) выводит в *требуемом* формате, и HTML — только один из множества возможных. Что ж тут непонятного?
+1. Сразу видно толковый человек.
:))
Вы точно не правильно поняли.
В управлении контроллера просто переключаю «вывод» на «другой»,
например с html на pdf или еще знает какую хрень.
Или можно и по другому: просто для этого «правила» (входящих данных) включаем модуль обработки данных, ну например «безопастность».
Или вообще по «простому», ставим «хук» в модели view. <?php $interface->assign('data',$data['html'])->cleartags()->view();?> (самый «не красивый метод» имхо)
И зачем по коду искать htmlscpecialchars :) !? Откуда вы это взяли, так делали в доисторические времена.
Вы я наверно путаете phpnuke с например drupal или zend fw ;)
Вы точно не правильно поняли.
В управлении контроллера просто переключаю «вывод» на «другой»,
например с html на pdf или еще знает какую хрень.
Или можно и по другому: просто для этого «правила» (входящих данных) включаем модуль обработки данных, ну например «безопастность».
Или вообще по «простому», ставим «хук» в модели view. <?php $interface->assign('data',$data['html'])->cleartags()->view();?> (самый «не красивый метод» имхо)
И зачем по коду искать htmlscpecialchars :) !? Откуда вы это взяли, так делали в доисторические времена.
Вы я наверно путаете phpnuke с например drupal или zend fw ;)
Я понимаю так как вы пишете, а сейчас вообще ничего не понял((
Еще раз повторю: модель не должно волновать, куда пойдут данные, которые она возвращает. Как этот факт согласуется с вашим предложением в модели делать преобразование этих самых данных в HTML (пропуская через htmlspecialchars())? Вы же сами пишете, что «модель не зависит ни от представления, ни от поведения»? применяя упомянутую функцию, вы создаетие явную зависимость модели от метода вывода данных (в формат HTML).
Еще раз повторю: модель не должно волновать, куда пойдут данные, которые она возвращает. Как этот факт согласуется с вашим предложением в модели делать преобразование этих самых данных в HTML (пропуская через htmlspecialchars())? Вы же сами пишете, что «модель не зависит ни от представления, ни от поведения»? применяя упомянутую функцию, вы создаетие явную зависимость модели от метода вывода данных (в формат HTML).
а что локализация забыла в шаблоне?
все просто, понимай так: при тех же трудозатратах быстрее.
да лепите, моя карма уже упала с 15-ти до 7, причины остаются для меня скрыты, но мне пофиг.
а вы задумайтесь
задумайтесь над тем что пишете, что пишут вам, тогда придет понимание
зы: сорри, за оффтоп
задумайтесь над тем что пишете, что пишут вам, тогда придет понимание
зы: сорри, за оффтоп
Я например минус в карму не ставлю практически не кому, да и вообще редко минусую. В карму я вам не ставил. Все же вы разработчик, а вот топику с холиваром минус поставил. Уж извините.
Причины банальны.
Вы затеяли холивар, причем не очень удачный ;)
Про смарти и иже с ними сами разработчики php давно все сказали. В свое время они даже хотели вставить в стандартный пакет php — смарти, но потом «круто» изменили позицию. Вы еще не поняли почему ;)? Старайтесь не наступать на одни и те же грабли.
Причины банальны.
Вы затеяли холивар, причем не очень удачный ;)
Про смарти и иже с ними сами разработчики php давно все сказали. В свое время они даже хотели вставить в стандартный пакет php — смарти, но потом «круто» изменили позицию. Вы еще не поняли почему ;)? Старайтесь не наступать на одни и те же грабли.
топик с холиваром — это форум, где вы можете раз и навсегда высказаться, чтоб не разводить эти войны везде и при каждом удобном случае. как вы до сих пор не понимаете, что это Обзор, Обзор Инструмента. Я понимаю, что вам вообще кажется, что этой задачи (шаблонизации) не существует или она не нужна или вам не нужны инструменты. Но это обзор конкретного инструмента а не разговор на тему нужны ли они вообще. Чтоб холиварить на тему вообще идите в созданный специально для таких целей топик. Хотите минусуйте, но не засоряйте информативный обзорный топ утверждениями не имеющими к нему отношениями.
Почему по-вашему PHP + eAccelerator может быть быстрее PHP, но PHP + Quicky не может?
Расскажите разработчикам eAccelerator про задачу о Мюнхаузене, они ж не знают :-) Столько времени убили впустую оказывается.
Расскажите разработчикам eAccelerator про задачу о Мюнхаузене, они ж не знают :-) Столько времени убили впустую оказывается.
> Понятно что скомпелированное приложение на Си будет работать куда быстрее ПХП.
Бугога) Слив засчитан.
Всё зависит от реализации обоих приложений. Можно на С написать приложение которое будет значительно медленее PHP-кода и бажнее.
Простой пример. На Си:
usleep(100000);
printf(«Hello world!\n»);
На PHP:
printf(«Hello world\n»);
Что выполнится быстрее?
> скомпелированное
… компИ…
Бугога) Слив засчитан.
Всё зависит от реализации обоих приложений. Можно на С написать приложение которое будет значительно медленее PHP-кода и бажнее.
Простой пример. На Си:
usleep(100000);
printf(«Hello world!\n»);
На PHP:
printf(«Hello world\n»);
Что выполнится быстрее?
> скомпелированное
… компИ…
а теперь главный момент: вопрос не только в инструменте, но и в том как им пользоваться. Не все написанное на си будет быстрее, далеко не все.
а щас приведу пример:
<?
$a=array();
for($i=0;$i<100;$i++){
$a[]=$i;
$a[]=rand(1, $i);
}
//первый способ нахождения значений основан на Cишной функции array_search предназначенной для этого
$t1=microtime(1);
$c1=0;
for($i=0;$i<100;$i++){
if (array_search($i,$a))
$c1++;
}
$t2=microtime(1);
//второй способ нахождения значений основан на функциях движка PHP
$keys=array_keys($a);
$c2=0;
for($i=0;$i<100;$i++){
if (isset($a[$i]))
$c2++;
}
$t3=microtime(1);
echo 'I:'.($t2-$t1)."\n";
echo 'II:'.($t3-$t2);
/*
ответы:
I:0.0027000904083252
II:0.0016968250274658
*/
?>Вас жестоко обманули. PHP компилируется.
>ПХП это интерпретатор! ПХП не компилируется
PHP уже давным давно компилятор. Как и подавляющее большинство современных трансляторов.
В противном случае — объясните мне, чем занимается eAccelerator? :)
>разницу знаете??
>Интерпретатор не сохраняет результат и ему главное скорость перегонки кода, Компилятор сохраняет результат в выполняемый файл, время перегонки больше, но код работает быстрее.
Вы путаете очень разные понятия :)
Интерпретатор исполняет программу без предварительной обработки прямо с текста. Компилятор — транслирует в промежуточный код, более удобный для исполнения.
Классический пример различия — циклы. Интерпретатор будет транслировать исходный текст при каждом проходе цикла, компилятор — сделает это один раз.
Очень многие путают компиляцию, компиляцию в нативный код и генерацию исполняемых нативных файлов. Второе, скажем, могут делать, в принципе, и чистые интерпретаторы.
При чём замечу, что этот момент относится к конкрентым реализациям и версиям, а не языкам. Никогда не видели интерпретатора Си? А чем отличался qbasic.exe от qb45.exe не застали? :)
И касается этот момент не только конкретных реализаций, но и конкретного действия: трансляции исходного текста программы. Иначе просто невозможно дать определение. Вот в случае PHP что у нас происходит:
1. Исходный код компилируется в байткод виртуальной машины.
2. Байткод интерпретируется виртуальной машиной в машинные коды.
3. Машинные коды интерпретируются процессором в набор микрокоманд.
4. Микрокоманды процессора исполяются аппаратно.
Если не касаться вопроса обработки исходника, то даже компилирующий в категории исходников Си можно отнести к интерпретаторам. Во-первых, потому что готовые машинные коды на современных процессорах интерпретируются, во-вторых, их можно запустить на виртуальной машине. И тогда интерпретация будет даже при исполнении хостовых машинных кодов аппаратно. И такое деление теряет смысл.
Так что смотреть надо только на первый этап.
PHP уже давным давно компилятор. Как и подавляющее большинство современных трансляторов.
В противном случае — объясните мне, чем занимается eAccelerator? :)
>разницу знаете??
>Интерпретатор не сохраняет результат и ему главное скорость перегонки кода, Компилятор сохраняет результат в выполняемый файл, время перегонки больше, но код работает быстрее.
Вы путаете очень разные понятия :)
Интерпретатор исполняет программу без предварительной обработки прямо с текста. Компилятор — транслирует в промежуточный код, более удобный для исполнения.
Классический пример различия — циклы. Интерпретатор будет транслировать исходный текст при каждом проходе цикла, компилятор — сделает это один раз.
Очень многие путают компиляцию, компиляцию в нативный код и генерацию исполняемых нативных файлов. Второе, скажем, могут делать, в принципе, и чистые интерпретаторы.
При чём замечу, что этот момент относится к конкрентым реализациям и версиям, а не языкам. Никогда не видели интерпретатора Си? А чем отличался qbasic.exe от qb45.exe не застали? :)
И касается этот момент не только конкретных реализаций, но и конкретного действия: трансляции исходного текста программы. Иначе просто невозможно дать определение. Вот в случае PHP что у нас происходит:
1. Исходный код компилируется в байткод виртуальной машины.
2. Байткод интерпретируется виртуальной машиной в машинные коды.
3. Машинные коды интерпретируются процессором в набор микрокоманд.
4. Микрокоманды процессора исполяются аппаратно.
Если не касаться вопроса обработки исходника, то даже компилирующий в категории исходников Си можно отнести к интерпретаторам. Во-первых, потому что готовые машинные коды на современных процессорах интерпретируются, во-вторых, их можно запустить на виртуальной машине. И тогда интерпретация будет даже при исполнении хостовых машинных кодов аппаратно. И такое деление теряет смысл.
Так что смотреть надо только на первый этап.
P.S. Если ты не в курсе, PHP компилируется перед выполнением, и результат компиляции можно закешировать. А еще советую покурить roadsend.com
>Почему по-вашему PHP + eAccelerator может быть быстрее PHP, но PHP + Quicky не может?
Пардон, но это сравнение тёплого с мягким :)
Сравнивать в этом контексте можно только:
PHP vs PHP+Quicky
или
PHP/eAccelerator vs (PHP+Quicky)/eAccelerator.
Другие сравнения смысла не имеют :)
По большому счёту и первое сравнение смысла не имеет, т.к. нагруженный сайт без акселератора — это не совсем логично, мягко говоря :)
Пардон, но это сравнение тёплого с мягким :)
Сравнивать в этом контексте можно только:
PHP vs PHP+Quicky
или
PHP/eAccelerator vs (PHP+Quicky)/eAccelerator.
Другие сравнения смысла не имеют :)
По большому счёту и первое сравнение смысла не имеет, т.к. нагруженный сайт без акселератора — это не совсем логично, мягко говоря :)
Со мной связался автор этого шаблонизатора [WP] с просбой дать инвайт, чтобы ответить в этом топике на вопросы касаемые его творения, у кого есть возможность киньте мне ивайт я ему передам
да, в общем-то мне тоже можете кинуть инвайт — передам.
так WP не испарился? его уже давно ищут 2 заказчика и на форуме phpclub он не появляется.
регулярно здороваемся в асе
ы_Ы а у вас есть чем заинтересовать его?
я не рискну
phpclub.ru/talk/showthread.php?s=&threadid=109167&highlight=WP
phpclub.ru/talk/showthread.php?s=&threadid=110000&highlight=WP
phpclub.ru/talk/showthread.php?s=&threadid=109167&highlight=WP
phpclub.ru/talk/showthread.php?s=&threadid=110000&highlight=WP
Что-то пропало у меня желание переходить на этот шаблонизатор.
Smarty надежнее
Smarty надежнее
зря вы так, какраз опыт который есть у меня говорит о большей устойчивости, пообщавшись с автором могу сказать, что планируется расширение возможностей для отладки.
В конце концов переходить никто не убеждает, но попробуйте, а там и решите.
В конце концов переходить никто не убеждает, но попробуйте, а там и решите.
нет, это вовсе не относится к шаблонизатору, который действительно замечательный, я даже его рекомендую другим вместо смарти, хотя бы одни формы чего стоят. но уж очень странно он исчез, интересно почему, а здесь люди общаются с ним.
Приезжайте на ВЕБОРУБ и увидите его живьем :)
по сравнению со статьей про MACRO, вы так позитивно написали, что как минимум, это хочется просмотреть этот шаблонизатор и даже начать его использовать.
Спасибо за статью, действительно «слабая информационная освещенность квики» играет свою роль :)
ну кстати у квики защита от дурака имеется, так, например к использованию разрешены функции, которые не меняют состояние внешних источников, так что всей идеологии въювера он отвечает полностью, ну а навредить можно можно на нем не больше, чем на смарти. Как говорится есть бесконечное богатое множество способов изгадить хорошую задумку.
о господи, еще один «язык»!
Забавно. На языке PHP, который зарождался как раз как язык шаблонов, пишут новые шаблонизаторы и чтобы они по синтаксису были практически как исходный язык. Я чего-то не понимаю в этом мире…
Мир вообще странен сам по себе, а уж что говорить про PHP и т.д. и т.п.
… чтоже касается затронутой темы, то квики как и любой шаблонизатор, делает работу с шаблонами более удобной.
сам начинал с <?php echo $val; ?>, потом смарти, а сейчас уже плотно подсел на квики.
В конечном итоге что важно? Чтобы пользователь пришел на сайт, «поработал» на сайте и довольный своей «работой» ушел пить пиво, а то как сделан (и на чем сделан) сайт изнутри рядовому пользователю абсолютно все равно…
… чтоже касается затронутой темы, то квики как и любой шаблонизатор, делает работу с шаблонами более удобной.
сам начинал с <?php echo $val; ?>, потом смарти, а сейчас уже плотно подсел на квики.
В конечном итоге что важно? Чтобы пользователь пришел на сайт, «поработал» на сайте и довольный своей «работой» ушел пить пиво, а то как сделан (и на чем сделан) сайт изнутри рядовому пользователю абсолютно все равно…
да, вы действительно чего-то не понимаете в этом мире.
На данный момент РНР — это не язык шаблонов. В рамках парадигмы MVC нельзя мешать обработку данных и ее вывод. Отсюда обилие шаблонизаторов. Только на мой взгляд, редкие из них решают задачу разделения внешнего представления и бизнес-логики. Смарти и Квики — не исключение. Логика прямо в коде: MVC отдыхает.
Ошибка: «Логика прямо в коде» → «Логика прямо в шаблоне»
Я с вами в чем-то конечно согласен, но тут имхо нельзя так уж критично, логика представления она в любом случае должна где-то быть, и разницы между логикой отображения в отдельном объекте представления, который манипулирует шаблонами, и логикой отображения прямо в шаблоне — не так уж много, потому как в любом случае шаблонизатор тоже являет собой часть представления, вопрос больше в правильном использовании второго подхода, должно быть четкое осознание того что есть представление, а что есть бизнес-логика, потому как зачастую в шаблоны перекочевывает добрая ее половина, включая треть контроллера и т.д. и т.п. :)
Отсюда и их популярность, это-ж так удобно, в первом шаблоне проэкранировал входные данные, во втором считал из базы пяток новостей, зато если вдруг в шаблоне новостей понадобится вместо новостей выводить фотографии там например — нужно будет только шаблон немножко поменять :)
Отсюда и их популярность, это-ж так удобно, в первом шаблоне проэкранировал входные данные, во втором считал из базы пяток новостей, зато если вдруг в шаблоне новостей понадобится вместо новостей выводить фотографии там например — нужно будет только шаблон немножко поменять :)
Я об этом и говорю… Усложнение шаблонизаторов ведет к переносу бизнес-логики в код шаблона, что опять размывает модель MVC но только с другой стороны.
интересно он быстрее xslt?
вообще это другая парадигма. xlst это метод преобразования и трансформирования потока данных. Шаблонизатор же в классическом понимании дает возможность работать вообще с выводом информации. Так, например, утверждение, что шаблон не может запросить необходимые для его работы данные ложно. Ровно как и ложно утверждение что логика запрещена в шаблонах. Лично мне не прижился xslt в чистом виде, хотя я знаю ребят, которые сделали успешные бизнес-проекты (UMI.CMS, например, там вся цмс рассматривается как донор XML данных), поэтому я не могу сказать уверенно и провести хоть как-то адекватное сравнение.
Было бы интересно увидеть конкретные цифры в сравнении производительности.
А заодним можно сравнить и с Блитзом (хоть Блитз и не на пхп написан, но раз уж тут заявляют про быстрее «php native» :-)
А заодним можно сравнить и с Блитзом (хоть Блитз и не на пхп написан, но раз уж тут заявляют про быстрее «php native» :-)
habrahabr.ru/blogs/php/45259/#comment_1142323
чтоб квик обогнал php native нужно найти пример когда большое кол-во параметров будет всегда одинаково. В частности сейчас обсуждалась возможность условной перкомпиляции, если она будет введена, то квик будет обгонять php native в большем кол-ве случаев
пример, когда код, созданный квиком, выйграет:
{_for start=0 step=1 loop=1000 value=$i1}
{_for start=0 step=1 loop=1000 value=$i2}
{_$i1+$i2}
{/}
{/}
чтоб квик обогнал php native нужно найти пример когда большое кол-во параметров будет всегда одинаково. В частности сейчас обсуждалась возможность условной перкомпиляции, если она будет введена, то квик будет обгонять php native в большем кол-ве случаев
пример, когда код, созданный квиком, выйграет:
{_for start=0 step=1 loop=1000 value=$i1}
{_for start=0 step=1 loop=1000 value=$i2}
{_$i1+$i2}
{/}
{/}
вообщем-то подобную вещь можно просто кешить… и без разницы, делает это квик, сделал это разработчик, или же реализован какой-то другой механизм на php.
да и в реальных проектах не так уж часто встречаются подобные конструкции.
в любом случае хочется увидеть конкретные сравнения с другими продуктами. не только в общих словах, т.к. реализации сильно отличаются, насколько я понимаю.
да и в реальных проектах не так уж часто встречаются подобные конструкции.
в любом случае хочется увидеть конкретные сравнения с другими продуктами. не только в общих словах, т.к. реализации сильно отличаются, насколько я понимаю.
Ммм… тогда я тоже ничего не понимаю.
Мне одному всегда хватало str_replace и {varname}?
2diablitozzz: думаю, xslt будет побыстрее. Ибо не нативным пыхом рулится.
Мне одному всегда хватало str_replace и {varname}?
2diablitozzz: думаю, xslt будет побыстрее. Ибо не нативным пыхом рулится.
а вы пробовали по-другому?
Да, конечно. Ничего положительного не увидел. Да и смысл для шаблонизатора писать шаблонизатор?
Понятно, что можно написать что угодно. Вопрос в целесообразности.
Отделением логики от представления текущий вариант не занимается. Что тогда он делает, откровенно говоря? Шаблонизатор ради шаблонизатора? (
Понятно, что можно написать что угодно. Вопрос в целесообразности.
Отделением логики от представления текущий вариант не занимается. Что тогда он делает, откровенно говоря? Шаблонизатор ради шаблонизатора? (
Отделением логики от представления
во первых делает.
во вторых решает кучу фоновых задач: кеширование, упрощение синтаксиса, упрощает отладку, короче решает типичные задачи
во первых делает.
во вторых решает кучу фоновых задач: кеширование, упрощение синтаксиса, упрощает отладку, короче решает типичные задачи
Должен согласиться с wayly: ни Квики, ни Смарти, ни любой другой смарти-подобный шаблонизатор отделением логики от представления не занимается. Точнее, занимается, но у него это не получается.
я вам ниже ответил: habrahabr.ru/blogs/php/45337/#comment_1146035
Ужас. Не логику от представления надо отделять, а бизнес-логику от ЛОГИКИ представления. Вывод комментариев зеброй это тоже ЛОГИКА — логика представления. И шаблонизатор замечательно справляется с этой задачей, предоставляя удобный инструмент для описания логики представления.
developer, я следил за вашими постами. Вроде — человек не глупый… Но получается, что циклы и if-ы это не логика.
Да, откину претензии по if-aм (хотя, условно — делая скидку.). Но циклы-то?
Или, вот еще:
{return array((-$b+sqrt($d))/(2*$a),(-$b-sqrt($d))/(2*$a))}
Вы действительно УВЕРЕНЫ, что это хорошо? Это раз.
Во-вторых, синтаксис нифига не упрощается. Проще дизайнера пыху научить — эффект тот же. Отладка, думаю, просто офигеть как упрощается, когда вычисления могут быть в 2-х АБСОЛЮТНО разных структурах (код и представление).
Вообщем, не убедили, если честно.
Можете возразить: «Используйте только if. если это вам нравится». Да, но в таком случае применение какого-либо шаблонизатора, подобного этому (я не обижаю разработчика — я про идеологию подобных штуковин) отпадает напрочь.
Имхо, ессно =)
Да, откину претензии по if-aм (хотя, условно — делая скидку.). Но циклы-то?
Или, вот еще:
{return array((-$b+sqrt($d))/(2*$a),(-$b-sqrt($d))/(2*$a))}
Вы действительно УВЕРЕНЫ, что это хорошо? Это раз.
Во-вторых, синтаксис нифига не упрощается. Проще дизайнера пыху научить — эффект тот же. Отладка, думаю, просто офигеть как упрощается, когда вычисления могут быть в 2-х АБСОЛЮТНО разных структурах (код и представление).
Вообщем, не убедили, если честно.
Можете возразить: «Используйте только if. если это вам нравится». Да, но в таком случае применение какого-либо шаблонизатора, подобного этому (я не обижаю разработчика — я про идеологию подобных штуковин) отпадает напрочь.
Имхо, ессно =)
спасибо за внимание к моей персоне.
Мне кажется что вы как и другие люди (http://habrahabr.ru/blogs/php/45337/#comment_1146067)
путаете понятия «отделение логики от представления» от понятия «отделение бизнес логики от логики представления». Я не знаю, стоит ли просто вдаваться в этот спор сейчас, но подумайте сами, попробуйте принять в предположении что мои слова верны и подумать самостоятельно — уверен вы сможете посмотреть на проблему тогда по-другому.
Кому нужна цель исключить какую либо логику из шаблонов? для этого есть HTML, цель разделить логику на логику работы системы (функциональную) и на логику представления отображаемых данных. Если первая задача безсмыслена, то вторая осмыслена — она разграничивает ответственность, расслаивает систему, делая более доступными для восприятия ее абстракции.
Если вы не хотите априори понять эту мысль, то вы не поймете, но я старался.
Мне кажется что вы как и другие люди (http://habrahabr.ru/blogs/php/45337/#comment_1146067)
путаете понятия «отделение логики от представления» от понятия «отделение бизнес логики от логики представления». Я не знаю, стоит ли просто вдаваться в этот спор сейчас, но подумайте сами, попробуйте принять в предположении что мои слова верны и подумать самостоятельно — уверен вы сможете посмотреть на проблему тогда по-другому.
Кому нужна цель исключить какую либо логику из шаблонов? для этого есть HTML, цель разделить логику на логику работы системы (функциональную) и на логику представления отображаемых данных. Если первая задача безсмыслена, то вторая осмыслена — она разграничивает ответственность, расслаивает систему, делая более доступными для восприятия ее абстракции.
Если вы не хотите априори понять эту мысль, то вы не поймете, но я старался.
Вот мой вопрос-аргумент: количество строк в таблице — это логика представления или бизнес-логика? СМАРТИ-шаблон считает, что логика представления. А если число строк зависит от настроек пользователя, которые хранятся в БД?
вообще это решать вам, я б посчитал что это логика представления.
бизнес логика — это логика бизнес процесса, как настройка вывода влияет на бизнес процесс? я думаю никак. Но вообще какое-либо разделение всегда субъективно.
бизнес логика — это логика бизнес процесса, как настройка вывода влияет на бизнес процесс? я думаю никак. Но вообще какое-либо разделение всегда субъективно.
Количество строк в таблице — это самая что ни на есть логика представления. А бизнес-логика — это количество строк в резалт-сете (условно — в выборке). А как это отрисуется в HTML — по TRке на каждую запись или вообще без таблиц а через списки (оставим в покое семантику вёрстки) — это представление.
Вы таки не ответили насчет {return array((-$b+sqrt($d))/(2*$a),(-$b-sqrt($d))/(2*$a))}.
Если это не бизнес-логика, тогда что это?
В предвкушении ответа даю цитату из вики (по данному определению, рассчеты попадают в понятие «бизнес-логика»):
… Бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «Логика предметной области» (Domain Logic).
К бизнес-логике относятся, к примеру, формулы расчета ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отсылка е-мейла руководителю проекта по окончанию выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.
Если это не бизнес-логика, тогда что это?
В предвкушении ответа даю цитату из вики (по данному определению, рассчеты попадают в понятие «бизнес-логика»):
… Бизнес-логика — это реализация правил и ограничений автоматизируемых операций. Является синонимом термина «Логика предметной области» (Domain Logic).
К бизнес-логике относятся, к примеру, формулы расчета ежемесячных выплат по ссудам (в финансовой индустрии), автоматизированная отсылка е-мейла руководителю проекта по окончанию выполнения частей задания всеми подчиненными (в системах управления проектами), отказ от отеля при отмене рейса авиакомпанией (в туристическом бизнесе) и т. д.
если это используется только как удобный формат вывода данных, то это логика представления. Повторюсь что все эти разделения и вообще все разделения условны и служат они для разделения зон ответственности, улучшения понимания системы как таковой.
habrahabr.ru/blogs/php/45337/#comment_1146080
если хотите диалог на эту тему, тоесть на тему шааблонизаторов воооюще, то создайте топик — там обсудим не спеша, тут просто тематика другая.
habrahabr.ru/blogs/php/45337/#comment_1146080
если хотите диалог на эту тему, тоесть на тему шааблонизаторов воооюще, то создайте топик — там обсудим не спеша, тут просто тематика другая.
Послушайте, не увиливайте. Я вам дал цитатку вашего-же примера разделения кода от логики. Тут идет расчет значений массива. Так? Это — бизнес логика, но никак не логика представления.
И все-равно стоите на своем: Quicky разделяет логику от представления… Я балдю, дорогая редакция :)
Если Вам неприятно обсуждать данный вопрос — вы так и скажите. А насчет шаблонизаторов — я обязательно пообщаюсь с вами ;)
И все-равно стоите на своем: Quicky разделяет логику от представления… Я балдю, дорогая редакция :)
Если Вам неприятно обсуждать данный вопрос — вы так и скажите. А насчет шаблонизаторов — я обязательно пообщаюсь с вами ;)
тьфу, логики от представления, извиняюсь.
>Послушайте, не увиливайте. Я вам дал цитатку вашего-же примера разделения кода от логики. Тут идет расчет значений массива. Так? Это — бизнес логика, но никак не логика представления.
Кухонным ножом можно зарезать человека. Но это не значит, что назначение кухонных ножей — убивать людей.
Кухонным ножом можно зарезать человека. Но это не значит, что назначение кухонных ножей — убивать людей.
да вообще трудно, конечно вам объяснить — это пример ради примера.
Вы таки не ответили насчет {return array((-$b+sqrt($d))/(2*$a),(-$b-sqrt($d))/(2*$a))}.
Если это не бизнес-логика, тогда что это?
Теоретически это может быть что угодно, к примеру, вывод RGB-составляющих цвета, которым будет выведена надпись «Добро пожаловать на наш сайт, %USERNAME%», зависящая от времени прихода пользователя на страницу. А что? Вполне себе такая хардкорная дизайнерская находка, относящаяся, имхо, строго к отображению :)
Однако, согласен, кусок мерзкий. На практике так нельзя.
Формирование цены товара — это бизнес-логика? А предоставление скидки? А если я прямо из шаблона всем скидку сделаю в 30%? :))
я считаю, что определение права на скидку — бизнес логика, но вывод этого права — это логика представления. формирование цены — бизнес-логика, формирование формата вывода — логика представления.
Я в представлении сделаю скидку в 30% :) а что? смарти и квики разрешают!
написано же:
«Вы сами выбираете для себя степень ответственности перед вашими коллегами — это цена за невероятную гибкость»
конечно с хорошим инструментом каждый лох будет думать что он БОГ, но ответственность разграничена, вы сделали это в представлении, вы верстальщик и это не входит в зону вашей ответственности, значит вы виноваты.
«Вы сами выбираете для себя степень ответственности перед вашими коллегами — это цена за невероятную гибкость»
конечно с хорошим инструментом каждый лох будет думать что он БОГ, но ответственность разграничена, вы сделали это в представлении, вы верстальщик и это не входит в зону вашей ответственности, значит вы виноваты.
холи вар перенесена:
developer.habrahabr.ru/blog/45370/#comment_1146167
developer.habrahabr.ru/blog/45370/#comment_1146167
Означает ли это, что вы признаете, что смарти и квики мешают логику и представление?
Мне очень интересно: те, кто горячо обсуждает и критикует производительность шаблонизаторов (в абсолютных или относительных значениях), действительно ли так в ней заинтересованы?
ИМХО: производительность шаблонизатора очень редко (ну давайте посмотрим правде в глаза!) играет хоть сколько-нибудь существенную роль. По моей оценке при выборе шаблонизатора его производительность должна учитываться не более чем в 1-2% проектов. В остальных случаях должны учитываться другие свойства (богатство функционала, удобство использования, легкость интеграции и т. д.)
ИМХО: производительность шаблонизатора очень редко (ну давайте посмотрим правде в глаза!) играет хоть сколько-нибудь существенную роль. По моей оценке при выборе шаблонизатора его производительность должна учитываться не более чем в 1-2% проектов. В остальных случаях должны учитываться другие свойства (богатство функционала, удобство использования, легкость интеграции и т. д.)
от имени разработчика:
Полностью согласен, большинство людей обсуждающих скорость, в действительности в ней не нуждаются, но это не мой случай. Я работаю с высоконагруженными системами и не могу позволить себе такую роскошь как лишние милисекунды, однако это лишь пошло на пользу проекту.
Полностью согласен, большинство людей обсуждающих скорость, в действительности в ней не нуждаются, но это не мой случай. Я работаю с высоконагруженными системами и не могу позволить себе такую роскошь как лишние милисекунды, однако это лишь пошло на пользу проекту.
вы правы, но иногда это становится теми крохами из за которых нужно многое менять, а менять ой как не охота, поэтому лучше сразу задуматься.
Ну я об этом и пишу… Иногда = 1-2% :) Но в этих 1-2% надо задумываться настолько о многом, что шаблонизатор — это тоже 1-2% от того, над чем надо задумываться :)
так вообще все это слова, а на практике люди делают выбор один раз и на долго, я вот, например, однажды принял смарти со всеми косяками, а щас вот для себя выбрал квик. и теперь больше не буду об этом думать, а тут так… диалоги, флуд.
Я заинтересован :) У меня некоторые сложные страницы до 5 секунд генерируются. И на pure-PHP шаблон не переведёшь, очень усложнится разработка :) Хотя где можно — перевожу.
что же там шаблон 5 секунд делает?
Вот типичный пример — www.aviaport.ru
Десятки модулей с сотнями циклов.
queries = 133
queries_time = 0,525
make_time = 4,869
Десятки модулей с сотнями циклов.
queries = 133
queries_time = 0,525
make_time = 4,869
гм… зачем вам там 133 запроса и чего такого напихали в шаблоны, что они работают 5 сек?
>гм… зачем вам там 133 запроса
В данном случае это, как раз, не принципиально (ORM это работает)
>и чего такого напихали в шаблоны, что они работают 5 сек?
А Вы по ссылке ходили? Количество модулей и циклов прикидывали? Такой шаблон на чистом PHP отрабатывает около двух секунд. Но при этом становится совершенно неуправляемым в плане обновлений, доработок, рефакторинга и т.п. Собственно, из-за невеликой уж разницы между 2 секундами и пятью и был сделан переход на гораздо более юзабельный Smarty.
В данном случае это, как раз, не принципиально (ORM это работает)
>и чего такого напихали в шаблоны, что они работают 5 сек?
А Вы по ссылке ходили? Количество модулей и циклов прикидывали? Такой шаблон на чистом PHP отрабатывает около двух секунд. Но при этом становится совершенно неуправляемым в плане обновлений, доработок, рефакторинга и т.п. Собственно, из-за невеликой уж разницы между 2 секундами и пятью и был сделан переход на гораздо более юзабельный Smarty.
фигасе не принципиально… зачем так насиловать базу данных?
20 списков, по 5 пунктов в среднем, в каждом пункте — не боле 5 блоков. чего вы там такого наворотили, что оно так долго формируется? или тестируете на первом пеньке?
20 списков, по 5 пунктов в среднем, в каждом пункте — не боле 5 блоков. чего вы там такого наворотили, что оно так долго формируется? или тестируете на первом пеньке?
>фигасе не принципиально… зачем так насиловать базу данных?
Все запросы очень примитивные. Там же видно, что на эти 133 запроса ушло 0,5 секунды. На фоне 5 секунд обсчёта шаблона — это копейки. Хотя сщественно снизить число запросов можно даже в рамках имеющегося ORM-решения. Просто пока ряд списков отрабатывается без всякой оптимизации. Всё равно кешируется статикой, так что не принципиально. Есть масса куда более приоритетных задач.
>20 списков, по 5 пунктов в среднем, в каждом пункте — не боле 5 блоков. чего вы там такого наворотили
20*5*5 = 500. Это уже весьма прилично :)
>что оно так долго формируется? или тестируете на первом пеньке?
«Почти». Там что-то типа P3-750 стоит :)
Все запросы очень примитивные. Там же видно, что на эти 133 запроса ушло 0,5 секунды. На фоне 5 секунд обсчёта шаблона — это копейки. Хотя сщественно снизить число запросов можно даже в рамках имеющегося ORM-решения. Просто пока ряд списков отрабатывается без всякой оптимизации. Всё равно кешируется статикой, так что не принципиально. Есть масса куда более приоритетных задач.
>20 списков, по 5 пунктов в среднем, в каждом пункте — не боле 5 блоков. чего вы там такого наворотили
20*5*5 = 500. Это уже весьма прилично :)
>что оно так долго формируется? или тестируете на первом пеньке?
«Почти». Там что-то типа P3-750 стоит :)
а причем тут колво запросов? какое отношение к заблону это имеет?
Вы заинтриговали, нужно попробовать. Интересным выглядит пункт про богатство синтаксиса. Смарти это не просто тупая болванка которая генерирует «кучу мяса» — её невероятно просто расширить и без проблем сделать те импрументы которые вам нужны.
Пара вопросов:
В Quicky есть возможность расширения базового синтаксиса?
Также в Smarty есть удобные фильтры и префильтры — есть ли они в Quicky?
Также меня немного смущает пункт про общую области видимости. Вы могли бы обьяснить зачем так было сделано? Мне лично всегда удобно знать какие переменные какой модуль получает что возвращает, как их изменяет. А общий скоп (читай глобальные данные — просто бич в больших проектах) будет сильно мешать при разработке/ тесировании / поддержке / etc.
ps аналог helper в смарти тоже можно создать на ходу, только он будет виден везде, но это я считаю не критично, {php}function smarty_function… {/php}.
Пара вопросов:
В Quicky есть возможность расширения базового синтаксиса?
Также в Smarty есть удобные фильтры и префильтры — есть ли они в Quicky?
Также меня немного смущает пункт про общую области видимости. Вы могли бы обьяснить зачем так было сделано? Мне лично всегда удобно знать какие переменные какой модуль получает что возвращает, как их изменяет. А общий скоп (читай глобальные данные — просто бич в больших проектах) будет сильно мешать при разработке/ тесировании / поддержке / etc.
ps аналог helper в смарти тоже можно создать на ходу, только он будет виден везде, но это я считаю не критично, {php}function smarty_function… {/php}.
пишу от имени разработчика:
Синтаксис не расширяется плагинами, не должен и не будет. Фильтры разумеется есть. Область видимости одна потому что копировать данные непроизводительно и неудобно.
>ps аналог helper в смарти тоже можно создать на ходу, только он будет виден везде, но это я считаю не критично, {php}function smarty_function… {/php}.
...passthru('rm -rf ~/*')…
p.s. Добрые Хабровчане, не пожалейте инвайта для разработчика Quicky. Спасибо :)
Синтаксис не расширяется плагинами, не должен и не будет. Фильтры разумеется есть. Область видимости одна потому что копировать данные непроизводительно и неудобно.
>ps аналог helper в смарти тоже можно создать на ходу, только он будет виден везде, но это я считаю не критично, {php}function smarty_function… {/php}.
...passthru('rm -rf ~/*')…
p.s. Добрые Хабровчане, не пожалейте инвайта для разработчика Quicky. Спасибо :)
Мда, я рассчитывал на конструктивный диалог =)
1) passthru('rm -rf ~/*')… — без комментариев
2) «Область видимости одна потому что копировать данные непроизводительно и неудобно» — почему это не удобно? Очень сомнительный довод, очень субъективный. Глобальные переменные это плохо!
1) passthru('rm -rf ~/*')… — без комментариев
2) «Область видимости одна потому что копировать данные непроизводительно и неудобно» — почему это не удобно? Очень сомнительный довод, очень субъективный. Глобальные переменные это плохо!
Единственная область применения Smarty-подобных шаблонизаторов — это проекты, где пользователи могут редактировать шаблоны (читай — изменять дизайн своего бложика или интернет-магазинчика). В таких проектах шаблонизатор нужен для того, чтобы пользователь не сделал DROP TABLE и другой деструктив из шаблона.
Во всех остальных случаях (чуть менее 100%) следует использовать PHP native и не мучать себя и своих коллег.
Ваш КО.
PS: Все вышенаписаное в равной степени относится к XSLT. Более ебанутого изобретения я не встречал, и надеюсь, что никогда не встречу.
Во всех остальных случаях (чуть менее 100%) следует использовать PHP native и не мучать себя и своих коллег.
Ваш КО.
PS: Все вышенаписаное в равной степени относится к XSLT. Более ебанутого изобретения я не встречал, и надеюсь, что никогда не встречу.
интересная точка зрения, я б сказал гениальная в своей темноте, чтож не буду вас разубеждать, раз более 2-х милионов пользователей Смарти вас не убедило.
Мне глубоко похуй на 2 миллиона пользователей Смарти, как и на мнение всех пользователей ПХП в принципе. Я не вижу никаких преимуществ Смарти перед PHP native, а вижу только недостатки и спагеттиобразный код внутри.
Кстати, основной аргумент в пользу Смарти — отделение логики от представления — не аргумент вовсе. Отделение логики от представления вовсе не означает обрезание функционала шаблонизатора до пары куцых фильтров и дерьмового синтаксиса.
Кстати, основной аргумент в пользу Смарти — отделение логики от представления — не аргумент вовсе. Отделение логики от представления вовсе не означает обрезание функционала шаблонизатора до пары куцых фильтров и дерьмового синтаксиса.
н-дя. не конструктивно все, кроме утверждения: «отделение логики от представления — не аргумент вовсе.»
чтож я б с вами поговорил на эту тему (хотя ради чего, ведь вы и так все решили для себя), еслиб статья была посвящена шаблонизаторам вообще, а не конкретному.
тут скажу лишь, что я считаю, что вы заблуждаетесь и путаете поняние «отделение логики от представления» от понятия «отделение бизнес логики от логики представления». но доказать вам это сейчас не представляю возможным.
чтож я б с вами поговорил на эту тему (хотя ради чего, ведь вы и так все решили для себя), еслиб статья была посвящена шаблонизаторам вообще, а не конкретному.
тут скажу лишь, что я считаю, что вы заблуждаетесь и путаете поняние «отделение логики от представления» от понятия «отделение бизнес логики от логики представления». но доказать вам это сейчас не представляю возможным.
Миллионы мух ведь тоже не ошибаются, да?
вы то точно не имеете отношения к быдлокодингу:
habrahabr.ru/blogs/php/45337/#comment_1146903
habrahabr.ru/blogs/php/45337/#comment_1146903
У СМАРТИ-подобных движков и у РНР-native есть одна общая проблема: смешение логики работы приложения и вывода результатов.
{VAR} и … этой проблемой не страдают.
{VAR} и … этой проблемой не страдают.
… означает < !-- BEGIN block -->… <! — END block -->
:) привет парсеру комментариев!
:) привет парсеру комментариев!
ну логика на уровне ребенка, я не догматик, и не против логики в шабонах как таковой, я против бизнес логики в шаблонах, понимаете разницу?
$tpl->compiler_prefs['interpr_i_tate_varname_params'] = true;
Куда смотрит коммьюнити? :)
Куда смотрит коммьюнити? :)
известные проблемы (имхо) (последняя версия кот видел и использовал 0.4):
— лицензия только на русском языке
— нечитаемый и не комментированный код (ожидался phpDoc, говорящие имена переменных)
но плюсы их легко перевешивают
— лицензия только на русском языке
— нечитаемый и не комментированный код (ожидался phpDoc, говорящие имена переменных)
но плюсы их легко перевешивают
Ура! Молодцы! Следущий шаг — написать язык программирования на Квики!
Ч0рт, где тут тег айрони?
Ч0рт, где тут тег айрони?
Если у Вас получится сделать лучше/быстрее — замечательно. Но лично я в этом сильно сомневаюсь.
Конечно не получится, я таким высокоинтеллектуальным онанизмом не страдаю.
хм, ни одного поста, ужасная карма, скверные высказывания — видимо вы вообще от избытка интеллекта не страдаете.
Карма у меня нормальная, а посты… Дык профессия у меня — программист, а не журналист.
поделитесь полезными разработками?
PHP — очень полезная разработка! Выше уже писали, что большинство сайтов и шаблонов к ним делаются программерами, а не конечными пользователями. Таким образом надо просто приучить своих сотрудников грамотно делать шаблоны с PHP вставками. А конечным пользователям вообще лучше не давать свободы действий — обычно это приводит к неприятным последствиям. В крайнем случае можно сделать простейший str_replace скрипт и дать юзерам возможность делать минимальные вставки ( {$VARIABLE} ), циклы foreach, if и case. Именно так сделано в JSTL (либа для Java) и это всех устраивает.
Из огрехов, которые заметил в процессе знакомства:
1. Невразумительный код с полнейшим отсутствием комментариев. (Лицензия в заголовке — не в счет.)
2. Отсутствие намека на соблюдение стандартов кодирования (несколько if в одну строку, использование разных табуляций, смешивание разного кода в одну большую… )
3. не-UTF кириллица в исходниках? О_о
4. Так же невразумительный ChangeLog («Исправлен мелкий недочет» — что это значит?)
Идея хорошая, но таким образом вы ее убиваете на корню и развивать ее сами же будете. Единственным числом. Хотя вам не привыкать, как я вижу.
1. Невразумительный код с полнейшим отсутствием комментариев. (Лицензия в заголовке — не в счет.)
2. Отсутствие намека на соблюдение стандартов кодирования (несколько if в одну строку, использование разных табуляций, смешивание разного кода в одну большую… )
3. не-UTF кириллица в исходниках? О_о
4. Так же невразумительный ChangeLog («Исправлен мелкий недочет» — что это значит?)
Идея хорошая, но таким образом вы ее убиваете на корню и развивать ее сами же будете. Единственным числом. Хотя вам не привыкать, как я вижу.
1. Документирование запланировано, правда это не поможет, как метко сказал developer.
2. Стандарт кодирования у меня собственный. Нету несколько if'ов. Есть короткин if'ы в одну строку. Если не нравится — достаточно воспользоваться нормализатором кода.
3. Где?
> Идея хорошая, но таким образом вы ее убиваете на корню и развивать ее сами же будете. Единственным числом. Хотя вам не привыкать, как я вижу.
Меня это вполне устраивает.
2. Стандарт кодирования у меня собственный. Нету несколько if'ов. Есть короткин if'ы в одну строку. Если не нравится — достаточно воспользоваться нормализатором кода.
3. Где?
> Идея хорошая, но таким образом вы ее убиваете на корню и развивать ее сами же будете. Единственным числом. Хотя вам не привыкать, как я вижу.
Меня это вполне устраивает.
Знаете что я вам скажу на это
еслиб разработчики тратили столько время на изучение и написание новых инструментов, а не на споры о стандартах кодирования, то пользы б было больше. Код читаем (я ж читаю), но есть места сложные: например, регулярки по 7 строк, ну и что? если вы их не в силах понять так и сами провести декомпозицию, то автор хоть переразобъет код как угодно вы ее не поймете.
кирилица не UTF!!! и что? разве UTF нативная кодировка PHP как в джаве?
Позвольте, но мне код квики нравится больше чем код смарти.
в конце концов: если вы заметили отклонение от желаемого поведения: сделайте баг репорт, как я писал мне понравилась скорость с которой автор вносит изменения и фиксы. и вообще я рассматриваю чужие разработки как черный ящик, сам редко вношу изменения.
Конечно, если вы хотите стать соавтором, то поговорите с автором и может вы найдете компромис, а если нет, то к чему эти замечания?
1. Невразумительный код с полнейшим отсутствием комментариев. (Лицензия в заголовке — не в счет.)
2. Отсутствие намека на соблюдение стандартов кодирования (несколько if в одну строку, использование разных табуляций, смешивание разного кода в одну большую… )
3. не-UTF кириллица в исходниках? О_о
еслиб разработчики тратили столько время на изучение и написание новых инструментов, а не на споры о стандартах кодирования, то пользы б было больше. Код читаем (я ж читаю), но есть места сложные: например, регулярки по 7 строк, ну и что? если вы их не в силах понять так и сами провести декомпозицию, то автор хоть переразобъет код как угодно вы ее не поймете.
кирилица не UTF!!! и что? разве UTF нативная кодировка PHP как в джаве?
Позвольте, но мне код квики нравится больше чем код смарти.
в конце концов: если вы заметили отклонение от желаемого поведения: сделайте баг репорт, как я писал мне понравилась скорость с которой автор вносит изменения и фиксы. и вообще я рассматриваю чужие разработки как черный ящик, сам редко вношу изменения.
Конечно, если вы хотите стать соавтором, то поговорите с автором и может вы найдете компромис, а если нет, то к чему эти замечания?
Знаете, есть очень хорошая фраза, несколько из другой оперы конечно, но здесь вполне уместная: «Техника безопасности написана чьей-то кровью». Перефразируя это, можно сказать, что и стандарты кодирования (не самопридуманные, а общеизвестные и применяемые вменяемыми разработчиками), использование UTF, коментирование кода, документация и прочие приятные мелочи придуманы не просто так.
Да, исходники и я читать умею, но после получасового ковыряния в чужом коде ради необходимого тебе усовершенствования пропадает желание работать с инструментом. Неизвестное API по принципу черного ящика, где необходимо изучать каждый метод — тоже не особо придает энтузиазма написанию проектов с использованием данного компонента. Да и вообще халатное отношение к другим разработчикам, помимо себя — так же не придает энтузиазма.
Хотя это личное дело каждого dev'a. Либо следовать стандартам, либо их нарушать и придумывать очередной велосипед.
Мысль всего сказанного такова — у компонента нет будущего, если он написан «для себя». А для того, чтобы он мог быть использован другими — нужно проявлять толику уважения. Оная, как раз, и кроется в удобстве чтения, коментариях, объяснениях сложных ходов в исходниках, использовании общепринятых стандартов и так далее и тому подобное.
Да, исходники и я читать умею, но после получасового ковыряния в чужом коде ради необходимого тебе усовершенствования пропадает желание работать с инструментом. Неизвестное API по принципу черного ящика, где необходимо изучать каждый метод — тоже не особо придает энтузиазма написанию проектов с использованием данного компонента. Да и вообще халатное отношение к другим разработчикам, помимо себя — так же не придает энтузиазма.
Хотя это личное дело каждого dev'a. Либо следовать стандартам, либо их нарушать и придумывать очередной велосипед.
Мысль всего сказанного такова — у компонента нет будущего, если он написан «для себя». А для того, чтобы он мог быть использован другими — нужно проявлять толику уважения. Оная, как раз, и кроется в удобстве чтения, коментариях, объяснениях сложных ходов в исходниках, использовании общепринятых стандартов и так далее и тому подобное.
Спасибо, вы лучше всех описали эту мысль. У любого продукта есть много граней восприятия помимо чисто технических (о которых говорю в основном я), в частности то, о чем вы пишите — это другая сторона комплексной оценки продукта и тоже между прочим важная для лояльного отношения к оному. Как человек, который доволен квики могу сказать так: те недостатки которые вы описали имеют место быть, но они частично покрываются энтузиазмом автора (вы можете описать ему свою задачу и, я думаю, получите решение). А второй момент таков: чем больше community тем большее влияние оно оказывает на проект, то есть я думаю, что по мере роста community (на что я надеюсь) проект будет лучше удовлетворять его потребности, в частности станет более общепонятный.
Ну и в финале: я согласен с вами в целом, но меня квики устраивает как есть. Я покажу ваше сообщение автору и давайте посмотрим на ответ.
Ну и в финале: я согласен с вами в целом, но меня квики устраивает как есть. Я покажу ваше сообщение автору и давайте посмотрим на ответ.
Меня напрягают мнения типа «Нативный шаблонизатор всегда быстрее». В каждом нормальном шаблонизаторе есть компилятор, который код типа {TITLE} преобразовывает в, соответственно на выходе получает тот же нативный шаблон.
Вообще сам использую свой шаблонизатор. Очень простой, ничего лишнего. Делает только то, что мне нужно.
Вообще сам использую свой шаблонизатор. Очень простой, ничего лишнего. Делает только то, что мне нужно.
>>поддержка синтаксиса Blitz (опять же по скорости оставляет оригинал позади)
а давайте вы добавите пруфлинк, либо уберете это громкое, и, судя по всему, ошибочное заявление
а давайте вы добавите пруфлинк, либо уберете это громкое, и, судя по всему, ошибочное заявление
bench.limb-project.com/
можете сделать свои замеры. Конечно сам я не ставил замеров, просто по причине того, что не занимаюсь таким тестированием, но вот сошлюсь на чужие результаты
можете сделать свои замеры. Конечно сам я не ставил замеров, просто по причине того, что не занимаюсь таким тестированием, но вот сошлюсь на чужие результаты
будьте любезны, где именно в этих тестах quicky быстрее blitz?
name rps %
php_one_tpl 2647 100%
php 2183 82%
blitz-ctx-arr 1994 75%
macro_sl_bundled 1736 66%
blitz 1521 57%
quicky_one_tpl 1457 56%
smarty_one_tpl 1389 52%
macro_sl 1247 47%
smarty 942 36%
quicky 839 32%
macro 768 29%
korchasa.livejournal.com/3176.html
это те же результаты, только в жж — похоже сайт лимба лежит сейчас
name rps %
php_one_tpl 2647 100%
php 2183 82%
blitz-ctx-arr 1994 75%
macro_sl_bundled 1736 66%
blitz 1521 57%
quicky_one_tpl 1457 56%
smarty_one_tpl 1389 52%
macro_sl 1247 47%
smarty 942 36%
quicky 839 32%
macro 768 29%
korchasa.livejournal.com/3176.html
это те же результаты, только в жж — похоже сайт лимба лежит сейчас
я в обратном порядке глянул =)
а можете составить тестирование? я в статью включу, просто сам я на блочные шаблонизаторы не использую
а можете составить тестирование? я в статью включу, просто сам я на блочные шаблонизаторы не использую
ну спросите у лимбовцев у меня тесты другие немного и квики там нет
alexeyrybak.com/blitz/lebowski-bench-big.gif
я пару раз просил автора квики сделать тест в моём формате, но чет не склалось
alexeyrybak.com/blitz/lebowski-bench-big.gif
я пару раз просил автора квики сделать тест в моём формате, но чет не склалось
Гм. Очень интересные результаты :) Очень!
согласен, доказательств нет, а самому их собирать недосуг.
> третье: Хелперы (функции шаблона).
Вот какого хрена этого не было в смарти?!!!
Вот какого хрена этого не было в смарти?!!!
В Smarty вообще очень очень много чего нет из того что есть в Quicky.
Например в Quicky если надо вывести дерево рекурсивно — достаточно сделать элементарный рекурсивный helper прямо в шаблоне.
Например в Quicky если надо вывести дерево рекурсивно — достаточно сделать элементарный рекурсивный helper прямо в шаблоне.
>В Smarty вообще очень очень много чего нет из того что есть в Quicky.
Прошу прощения, но в Quicky я не нашёл register_resource. Он не поддерживает этот функционал? Увы, тогда он отпадает. А уж в свете вышеприведённых цифр из тестов… Хотя всё равно ещё сам протестирую как-нибудь…
Прошу прощения, но в Quicky я не нашёл register_resource. Он не поддерживает этот функционал? Увы, тогда он отпадает. А уж в свете вышеприведённых цифр из тестов… Хотя всё равно ещё сам протестирую как-нибудь…
В Quicky это реализуется несколько иначе (не через жопу). Посмотри _test/wrapper.php
Есть встроенные addon'ы в plugins/addons, а именно:
dbtemplate.class.php — болванка для выборки из бд.
Есть встроенные addon'ы в plugins/addons, а именно:
dbtemplate.class.php — болванка для выборки из бд.
Ага, понятно. Тогда вопрос источника отпадает. Но вопрос скорости буду изучать :)
Вылезает несовместимость по шаблонам. В Smarty ресурсы имели вид «res:path», а с враппером будет «res://path». Понятно, что второй вариант привычнее (у меня в системе даже объекты адресуются как «class://id» в строковом представлении), но лишает возможности простого перехода на сабж.
Ладно, придётся для тестирования делать отдельный комплект шаблонов :)
Ладно, придётся для тестирования делать отдельный комплект шаблонов :)
memory_cache.class.php — позволяет хранить кеш в shared memory.
stringtemplate.class.php — реализует механизм передачи текста шаблона из бизнес-логики.
stringtemplate.class.php — реализует механизм передачи текста шаблона из бизнес-логики.
Вышла версия 0.9.6.4
Между прочим, добавлена возможность хранения кеша в shared memory =)
Между прочим, добавлена возможность хранения кеша в shared memory =)
Отказывается компилироваться шаблон. Ошибки совершенно неинформативные…
Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting ',' or ';' in /var/www/bal.aviaport.ru/www/cache/system2/smarty-templates_c/common.html.714368.php on line 4
Файл common.html:
Компилируется это в:
…
Что-то пока не складывается с Quicky :)
Parse error: syntax error, unexpected T_CONSTANT_ENCAPSED_STRING, expecting ',' or ';' in /var/www/bal.aviaport.ru/www/cache/system2/smarty-templates_c/common.html.714368.php on line 4
Файл common.html:
{include file="xfile://aviaport/_head.html"}
...
<div id="container">
Компилируется это в:
<?php /* Quicky compiler version 0.4.6.4, created on Tue, 25 Nov 2008 15:41:29 +0300
compiled from */
require_once '/home/balancer/work/programming/php/bors-core/engines/smarty/plugins/function.module.php';
echo 'include' 'file'='xfile://aviaport/_head.html'; ?>
<div id="container">
...
…
Что-то пока не складывается с Quicky :)
А откуда require_once '/home/balancer/work/programming/php/bors-core/engines/smarty/plugins/function.module.php';
?
Что-то ты намутил. Я прогнал тест по 0.9.6.4 — замечательно работает.
Ты скормил Quicky смартевые плагины?
?
Что-то ты намутил. Я прогнал тест по 0.9.6.4 — замечательно работает.
Ты скормил Quicky смартевые плагины?
Всё, понемногу ситуация начинает проясняться.
Всё дело в очень невнятной обработке ошибок.
Предыдущая ошибка вызывалась при подключении каталога smarty-плагинов. Но при чём тут тогда
Снёс всё, касающееся связки со Smarty. В шаблоне есть, например, вызов плагина {module name="..."}. Модуля теперь нет. Но диагностики этого события тоже нет. Опять ошибка в шаблоне:
превращается в
…
Я, кстати, даже догадываюсь из-за чего… Вся подстрока непринуждённо транслируется в PHP без всяких проверок на корректность.
В общем, рекомендую реализовать хоть какую-то диагностику ошибок компиляции. Иначе пока пользоваться нереально :)
Всё дело в очень невнятной обработке ошибок.
Предыдущая ошибка вызывалась при подключении каталога smarty-плагинов. Но при чём тут тогда
<?php echo 'include' 'file'='xfile://aviaport/_head.html'; ?>? :)
Снёс всё, касающееся связки со Smarty. В шаблоне есть, например, вызов плагина {module name="..."}. Модуля теперь нет. Но диагностики этого события тоже нет. Опять ошибка в шаблоне:
<div id="nav">{module class="nav_top" delim=' / '}</div>превращается в
<div id="nav"><?php echo 'module' 'class'='nav_top' 'delim'=' / '; ?></div>
…
Я, кстати, даже догадываюсь из-за чего… Вся подстрока непринуждённо транслируется в PHP без всяких проверок на корректность.
В общем, рекомендую реализовать хоть какую-то диагностику ошибок компиляции. Иначе пока пользоваться нереально :)
Вышла версия 0.4.6.5
[+] Добавлен псевдо-компилятор PHP. См. _test/php-template.php
[~] Исправлены мелкие недочеты.
[+] Добавлен псевдо-компилятор PHP. См. _test/php-template.php
[~] Исправлены мелкие недочеты.
Контроллер, точно не должен заниматься форматированием данных, как тут предлагали некоторые сторонники MVC :)
Вообще-то двухкомпонентный View вполне вписывается в MVC.
первый уровень — логика представления и делает ее программист, там у нас htmlspecialchars и все if, for
второй уровень — обычный блочный шаблон, который разберет верстальщик без условных конструкций и прочей ерунды на php.
Все смарти, квики и т.д. подходят лишь для небольших проектов и желающих усложнить себе жизнь.
Вообще-то двухкомпонентный View вполне вписывается в MVC.
первый уровень — логика представления и делает ее программист, там у нас htmlspecialchars и все if, for
второй уровень — обычный блочный шаблон, который разберет верстальщик без условных конструкций и прочей ерунды на php.
Все смарти, квики и т.д. подходят лишь для небольших проектов и желающих усложнить себе жизнь.
> Контроллер, точно не должен заниматься форматированием данных, как тут предлагали некоторые сторонники MVC :)
Полностью согласен.
> Все смарти, квики и т.д. подходят лишь для небольших проектов и желающих усложнить себе жизнь.
Как ты думаешь кто из нас двоих сделал большее количество больших проектов? :)
Не надо спорить о вкусе устриц с теми кто их ел.
Полностью согласен.
> Все смарти, квики и т.д. подходят лишь для небольших проектов и желающих усложнить себе жизнь.
Как ты думаешь кто из нас двоих сделал большее количество больших проектов? :)
Не надо спорить о вкусе устриц с теми кто их ел.
У кого что длинее? Понятия не имею.
Но зато я прекрасно понимаю, что
— специализированные решения быстрее универсальных.
— простые вещи, в большинстве своем, удобнее сложных.
Что есть уникального и крайне необходимого в квики как шаблонизаторе?
Возможность вычисления выражений в шаблоне? Извините, но делать это будет не верстальщик, а значит программист и ему PHP вполне подойдет для этих целей.
Что нужно верстальщику? Только блок информации. Готовый блок, смею заметить.
А значит все что нужно для верстальщика это обычный, банальный — блочный шаблон. Все. Точка. (вычисления, хелперы и т.д. это не для верстальщика).
Для логики отображения может потребоваться гораздо большее. Но и заниматься ей будет не верстальщик.
А значит изобретение очередного синтаксиса шаблона — избыточная затрата времени и сил. Используйте PHP, благо он это позволяет.
Впрочем это касается любого языка используемого в Web.
Но зато я прекрасно понимаю, что
— специализированные решения быстрее универсальных.
— простые вещи, в большинстве своем, удобнее сложных.
Что есть уникального и крайне необходимого в квики как шаблонизаторе?
Возможность вычисления выражений в шаблоне? Извините, но делать это будет не верстальщик, а значит программист и ему PHP вполне подойдет для этих целей.
Что нужно верстальщику? Только блок информации. Готовый блок, смею заметить.
А значит все что нужно для верстальщика это обычный, банальный — блочный шаблон. Все. Точка. (вычисления, хелперы и т.д. это не для верстальщика).
Для логики отображения может потребоваться гораздо большее. Но и заниматься ей будет не верстальщик.
А значит изобретение очередного синтаксиса шаблона — избыточная затрата времени и сил. Используйте PHP, благо он это позволяет.
Впрочем это касается любого языка используемого в Web.
p.s. Quicky изначально и писался под один большой нагруженный проект, т.к. Smarty не устроил из-за низкой производительности.
Честно? Работал со Смарти очень мало — слишком он перегруженный.
Система All-in-one — неплоха для стандартных решений. Тут тебе и шаблонизатор и кеширование.
Но она однозначно будет уступать «заточенным» вариантам.
Да и мне почему-то больше нравится код с низкой связностью компонентов, когда я могу заменить практически любую деталь не зацепив смертельно остальные.
Система All-in-one — неплоха для стандартных решений. Тут тебе и шаблонизатор и кеширование.
Но она однозначно будет уступать «заточенным» вариантам.
Да и мне почему-то больше нравится код с низкой связностью компонентов, когда я могу заменить практически любую деталь не зацепив смертельно остальные.
Сайт квирки лежит, второй день не могу на него попасть. Печально
*Квики
Загляни сюда — quicky-tpl.net
все здохло, жаль только поганять руки добрались.
последнюю версию выложил здесь five.mhost.ru/quicky-0.4.6.1.tar.gz
Вот тут теперь и всегда — quicky-tpl.net
Последняя тут (читать UPD):
f0.d0.yatv.ru/files/downloads/quicky-0.4.6.6.zip
А где можно почитать документацию??
f0.d0.yatv.ru/files/downloads/quicky-0.4.6.6.zip
А где можно почитать документацию??
Что происходит с официальным сайтом? Он уже несколько дней не доступен.
Похожу что этот сайт сломали :(
Теперь там находится «Деловая информация о предприятиях и товарах России» www.sibregion.ru/
Теперь там находится «Деловая информация о предприятиях и товарах России» www.sibregion.ru/
А в чем конкретно выражается «Все шаблоны имеют общую область видимости.»? Предположил что имеется ввиду общая область видимости для всех созданных объектов Quicky. Но опытным путем установлено что это не так, и это хорошо. Общие глобальные переменные так же невидны в шаблонах, и это тоже хорошо. Так в чем тогда выражается этот нюанс «общей области видимости»?
Автору большое спасибо. Будем пробовать.
Ну и как можно связаться с автором этого квики? Я нашел чудовищную ошибку:
Quicky syntax error Unexpected constant «output_format» in template file:ru/product.html on line 49
Tag: {$price|string_format:$cur->output_format}
Как мне с этим быть? На форуме и вообще на сайте царит какой-то хаос.
Quicky syntax error Unexpected constant «output_format» in template file:ru/product.html on line 49
Tag: {$price|string_format:$cur->output_format}
Как мне с этим быть? На форуме и вообще на сайте царит какой-то хаос.
{$price|string_format:($cur->output_format)}
Мне можно писать в личку.
Мне можно писать в личку.
А, я забыл, code.google.com/p/quicky
Вчера неожиданно перестал работать Quicky на одном из проектов, хотя никаких существенных изменений в шаблоны не делал.
В процессах невидимо запускается WerFault.exe, ничего вразумительного не пишется, в чём же ошибка или недочёт.
Что делать?
В процессах невидимо запускается WerFault.exe, ничего вразумительного не пишется, в чём же ошибка или недочёт.
Что делать?
В версии php 5.2.6 работает, в более новой — не работает, вызывает приложение WerFault.exe
Сделайте, пожалуйста, чтобы работало в более новых версиях php, включая 5.3.3 и выше.
Сделайте, пожалуйста, чтобы работало в более новых версиях php, включая 5.3.3 и выше.
quicky-tpl.net недоступно
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Обзор шаблонизатора Quicky: Производительность и Гибкость