Шаблонизатор на php своими руками


Шаблонизатор

Решил переписать свой шаблонизатор, ввести глобальные коды, elseif.

Какой шаблонизатор я вижу в будущем:

Вопрос в том, что, по вашему мнению, необходимо добавить в функционал?

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

UPD: На чем лучше парсить условия и циклы? Регулярные выражения или строковые функции?

3 ответа 3

Нет. Что Вы. Конечно это не будет велосипедом. Нормальные шаблонизаторы щас вообще трудно найти.

Ну, например, можете добавить цикл foreach, ну чтобы можно было например вывести массив данных. Скажем так:

Ну смысл вы поняли. Можно даже туда как-нибудь ключ массива привязать (т.е. foreach($array as $key => $value) ). Например так:

Можно добавить выполнение функций. Ну хотя у вас на это есть алиасы вроде. Вообще посмотрите тут. Довольно хороший шаблонизатор. Мне понравился. Единственно, что я бы от себя туда добавил, это запрет добавление обычного php-кода (ну просто мне очень нужна эта фича!).

без евала будет трудновато распарсить этот блок (но в общимто реально). А евал это всегда риск, особенно если не вы управляете контентом. Собсвенно я к тому что бы вы придумали попроще синтаксис в котором это можно было бы реализовать.

Опа, а как же ассоциативные массивы сделать.

После того как сделаете шаблонизатор попробуйте использовать его в какой-то простенькой, но реальной задаче. И вы сразу поймете всё ли работает правильно и чего действительно не хватает.

+я бы посоветовал еще добавить конвертеры.

где toTimeStr келбек функция которая преобразовывает переменную var156.

Поэксперементировав с этим вам наверное захочется добавить параметры в этот конвертор, например что бы задать формат времени, поэтому нужно также учесть параметры:

или даже именные параметры:

в общим тут полёт фантазии большой. Но в первую очередь подумайте что действительно нужно Вам.

Как по мне — не лучший формат, по сути я вообще не вижу причин использовать что-то подобное, чистая PHP шаблонизация только в профиль. Если вы хотите сделать действительно хороший шаблонизатор, тогда он должен быть быстрым и красивым. В вашем «концепте» я не вижу ни удобства, ни красоты ( говорю строго за себя ).

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

Ну и, возможно, сделайте что-бы переменную было по человечески видно, что-то типа [ someVar ] , < someVar >etc. т.к. не знаю как остальных, но как по мне — конкретно страдает читабельность такого кода $var$ . Вообще, в идеале — было бы неплохо написать код так, что-бы пользователи могли сами выбрать себе разделители, т.е. пускай хоть и <<<< var >>>> или OLOLOLOvarOLOLOLO делают если хотят. Ну и довольно важно — реализовать удобные базовые хелперы и возможность написания своих. Хелперы могут быть, например, для рекурсивного вывода, фильтрующими, форматирующими и т.д. и т.п.

Ну и реализуйте кэширование.

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

PS: как сформируете концепт — просмотрите существующие шаблонизаторы и подумайте — значительно отличается ли ваша задумка, сможете ли вы предложить продукт получше и т.д. Конечно это только если вы не исключительно в учебных целях пишите.

Шаблонизатор на php своими руками

В примере выше устанавливается обработчик, который на запрос главной страницы отдаст строчку Main Page. Такой пример хорошо подходит для демонстрации, но настоящие сайты отдают html. Причём, его размер может достигать килобайтов. Если мы попробуем создавать его так:

то такой код очень быстро превратится в неподдерживаемое месиво. Для работы с html во фреймворках используют специальные библиотеки, называемые шаблонизаторами. Принцип работы заключается в том, что в отдельном файле описывается шаблон, обычно представляемый как html с вкраплениями кода на целевом языке или псевдоязыке (примеры не из php):

Некоторые виды шаблона не очень похожи на html и крайне популярны в других языках:

А библиотека, в свою очередь, читает этот файл и подставляет необходимые переменные. Таким образом один шаблон может использоваться для разных данных. Например, на Хекслете множество уроков, но шаблон, который формирует html соответствующей страницы — один. Присмотритесь к шаблонам выше. Внутри них нередко используется свой язык с условными конструкциями, циклами и другими механизмами.

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

Получается, что сам файл — это html-код, в котором есть вставки php. Обратите внимание на то, что привычные конструкции имеют немного другой вид. В отличие от обычного кода, в котором мы используем фигурные скобки, в таком варианте используются : , и ключевые слова. Такой подход выбран разработчиками языка исключительно для удобства.

Безопасность

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

Уроки WordPress


Уроки разработки из собственного опыта

PHP >Автор: Николаенко Максим · Опубликовано Март 13, 2013 · Обновлено Август 8, 2020

Думаю каждый кто начинал программировать рано или поздно приходил к выводу что необходимо собирать готовые скрипты для оптимизации своей работы. Сегодня я начинаю новый раздел в котором хочу публиковать свои находки и наработки полезных php классов и буду рад если вы, мои дорогие читатели, тоже будете помогать в подборе полезных классов.

Хочу чтобы сайт стал настольной книгой для тех, кто хочет не только разрабатывать сайты на системах управления, но и делать свои системы управления. Польза в создании своей системы будет огромной и чтобы доказать это приведу простой пример. Не так давно я столкнулся с тем что при работе с клиентами мне очень не хватает систематичности в решениях. Каждый шаг при работе с клиентами должен был записываться и так чтобы клиенту это было не в напряг, я же понимаю что им учить еще и мою программу нет смысла. Порыскав по интернету я нашол несколько хороших систему работы с клиентами CRM но ни одна не подходила под мои задачи. Настройка найденых систем была громоздкой , а работа просто превратилась бы в бюрократию. С другой стороны, имея набор полезных классов можно было бы без труда разработать систему управления под себя.

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

Документация по макросам и шаблонам UMI.CMS

Начало работы с PHP-шаблонизатором

Настройки шаблона

Для того, что бы начать работу c шаблонизатором, необходимо перейти в настройки модуля “Структура” и на вкладке “Управление шаблонами” создать новый шаблон, после чего зайти в настройки созданного шаблона и выставить параметр тип шаблона в php .

Имя файла произвольное, например: default.phtml .

Файлы шаблона должны располагаться в директории:

В корне директории необходимо создать файл, с именем заданным в настройках.

Базовый шаблон

В простейшем виде базовый шаблон может выглядеть следующим образом:

/** @var umiTemplaterPHP $this */ ?>
/** @var array $variables */ ?>

$variables[‘@title’] ?>

Первые 2 строки:

/** @var umiTemplaterPHP $this */ ?>
/** @var array $variables */ ?>

подсказки IDE для вывода autocomplete.

Для организации иерархичной структуры хранения шаблонов можно воспользоваться следующей конструкцией:

$this -> render( $variables , $variables [ ‘@module’ ] . ‘/’ . $variables [ ‘@method’ ]) ?>

XTEN — простой компилирующий xml-шаблонизатор на php

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

Раньше он назывался XTL, теперь же я решил поменять его название на XTEN — Xml Templates ENgine.

Попробую тут его коротко описать :)

Идея шаблонизатора проста как пять копеек — в специальной папке расположены плагины шаблонизатора (я назвал их хендлерами), которые выполняются в случае, если для обрабатываемого шаблона сработает выражение XPATH, указанное внутри самих хендлеров. При этом хендлеры фактически являются xml-файлами с набором инструкций для компилятора — что делать, когда сработает этот хендлер. Эти инструкции называются экшнами и тоже хранятся в отдельных файлах в виде php-кода, который eval’ится шаблонизатором.

Вот пример простейшего хендлера:

Внутри тактх хендлеров поддерживается целый ряд подстановок, например конструкция

выведет параметр blabla тега, на который сработало выражение xpath. Если такого параметра нет, то шаблонизатор попытается вывести переменную шаблона с именем blablabla.

В приведенном примере хендлер содержит всего один экшн — replace. Этот экшн позволяет заменить тот тег шаблона, на который сработал хендлер. Кроме того, этот экшн умеет заменять не только сработавший тег, но и люой тег в шаблоне, например если немного поменять хендлериз примера:

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

У шаблонизатора есть еще одна возможность — он поддерживает указание переменных (вида $имя_переменной) в параметрах тегов, на которые срабатывают экшны, что позволяет написать в шаблоне например так:

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

(примечание: в текущей dev-версии экшн inject пока не реализован :D)

Вобщем, возможности XTEN как шаблонизатора весьма обширны :)


Не могу не заметить, что компиляция шаблонов является цикличной, то есть один хендлер может добавить код, на который в следующем цикле сработает другой хендлер. Кроме того, шаблонизатор кеширует результаты компиляции шаблонов, что весьма немаловажно для сайтов с большой нагрузкой, так как минимальная скорость компиляции шаблона у XTEN немаленькая — 0.3-0.5 секунды (для сравнения: предыдущая версия компилировала пустой шаблон меньше чем за сотую долю секунды (замеры делал на локальном компе)).

Теперь о грустном (хотя и не очень) :)

* Шаблонизатор работает только в php5;

* Шаблонизатор работает только c utf8. Ибо DOMDocument ругается на кириллицу в других кодировках (если знаете как это исправить — ткните меня носом, плиз :);

ЗЫ. если кто-нибудь захочет присоединиться к проекту — буду только рад :)

UPD: господа, ваши уставы в мой монастырь просьба не пихать. Юзаете другие решения (xslt, изврат с php в html и т.д.) — флаг вам в руки. Только избавьте меня от необходимости кому-то что-то доказывать.

Для особо умных:
Все комментарии, не относящиеся к теме поста будут мной тщательно удалены. В целях экономии как моего времени, так и вашего. У меня не стоит цели советоваться тут с вами — нужны ли шаблонизаторы или не нужны. И не стоит цели устраивать очередной холивар на эту тему, мне мое время дороже (кстати, если тут все такие супер спецы по вебдеву, то откуда у них есть время и желание участвовать в бесполезных спорах?). Именно поэтому все комментарии, являющиеся флудом или провокацией, будут мной удалены.

Разделение PHP и HTML кода, использование шаблонов

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

Почему необходимо отделять HTML от PHP? Причин может быть несколько:

  • смешивание кода HTML и PHP в одном файле выглядит некрасиво;
  • нет подсветки HTML синтаксиса, загромождается код PHP – ведь обычно HTML код занимает довольно много места;
  • невозможно повторное использование HTML кода в других местах веб-приложения;
  • когда будет необходимо вносить изменения в HTML – придется долго искать этот участок кода в файле с PHP кодом.

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

Для примера создадим файл с расширением tpl, в котором будет храниться HTML код. Это и будет наш шаблон, расширение файла можно сделать любое, tpl здесь просто для примера. Соответственно в редакторе кода можно задать подсветку синтаксиса HTML для этого расширения (к примеру в Notepad++). В этом файле прописываются нужные переменные, которые необходимо будет заменить на нужные данные. Пример шаблона:

Далее создаем некоторую функцию, например – myfunction, в которой есть данные и путь к шаблону:

Наконец, необходимо создать функцию get_html, которая будет выполнять работу по подключению указанного шаблона и заменять в нем данные. Функция принимает два параметра: путь к шаблону и данные. В цикле происходит проход по всему содержимому массива data и создаются переменные. Затем включается буферизация и подключается шаблон, в котором используются вышесозданные переменные. В завершении прекращаем процесс буферизации и возвращаем готовый HTML код. Примерный код приведен ниже:

Таким образом, отделить HTML от PHP кода без использования сторонних шаблонизаторов не составит труда. Использование шаблонов позволит сделать разработку проекта более удобной и правильной.

Шаблонизатор — основной скрипт сайта на php

Напишем один из основных php скриптов сайта шаблонизатор, которому определено уже место и название в нашем проекте D://Mysitephp/php/main.php. Но прежде напишем php скрипт файла index.php, который будет находиться в корне сайта и перенаправлять его загрузку, в частности его главной страницы на main.php.

Файл скрипта index.php будет состоять всего лишь из трех строк.

Как работает этот php скрипт? Достаточно просто. При попадании пользователя на главную страницу сайта index.php будет подключен скрипт шаблонизатора, тоесть main.php, который находится в папке php.

Не будем останавливаться на операторе include. Об этом можно почитать в справочнике по php, о котором шла речь ранее. А для информации: Оператор include() подключает и вычисляет специфицированный файл. Когда файл подключён/included, содержащийся в нём код наследует область видимости переменной строки, на которой возникло подключение. Любые переменные, доступные на этой строке в вызывающем файле, будут доступны в вызываемом файле, вперёд от этой точки. Простыми словами оператор include подключает в работу скрипт прописанный в файле путь к которому заключен в «. » и находится в строке сразу после самого слова include, тоесть в нашем случае main.php.

Ну, а сам main.php будет посложнее:

// загрузка в переменные, в виде строк, содержимого страниц и меню
$title = «Титул страницы»;
$meta = file_get_contents («templates/pages/meta/rub1_part1_meta.html»);
$text = file_get_contents («templates/pages/rub1_part1.html»);
$titlepage = «Заголовок страницы»;
$rubric1 = «Меню рубрики 1»;
$rubric2 = «Меню рубрики 2»;
$rubric3 = «Меню рубрики 3»;

// функция по перемещению и замене строк в частях шаблона на содержимое переменных
function repl ($path)
<
// определение глобальных переменных
global $title,$meta,$titlepage,$text,$rubric1,$rubric2,$rubric3;

// чтение файла в виде строки в переменную $temp
$temp = file_get_contents($path);

// перемещение участков в строке загруженной в $temp
$temp = str_replace ( «%title%», $title, $temp );
$temp = str_replace ( «%meta%», $meta, $temp );
$temp = str_replace ( «%titlepage%», $titlepage, $temp );
$temp = str_replace ( «%text%», $text, $temp );
$temp = str_replace ( «%rubric1%», $rubric1, $temp );
$temp = str_replace ( «%rubric2%», $rubric2, $temp );
$temp = str_replace ( «%rubric3%», $rubric3, $temp );

Илон Маск рекомендует:  @viewport в CSS

// вывод измененной строки содержащейся в переменной $temp
echo («$temp»);
>

Прощай Smarty, или Простой шаблонизатор

Н а прошлой недели запускал один проект и что-то мне не понравилась скорость генерации страниц. Начал искать в чём дело. Оказалось, в шаблонизаторе!

Д умаю, очень многие разработчики используют в качестве шаблонизатора Smarty. По-моему, Smarty — самый известный шаблонный движок. Чем он знаменит?

  • лёгок в освоении, понятен даже человеку, не владеющему PHP;
  • легко интегрируется в готовые проекты;
  • очень функционален, обладает практически своим языком программирования.

И вот тут-то «собака и зарыта». Программисты, использующие Smarty, пушат шаблоны на его (довольно корявом) языке, чтобы шаблонизатор потом постоянно перегонял эти шаблоны в php-код (куча никому не нужной работы. ). Если вдуматься, получается самая большая глупость во всей истории программирования на PHP!


Н е проще ли сразу писать шаблоны на PHP?

К акая разница писать: или (либо )? Да первый вариант, короче. Но это, скорее, дело привычки, а вот скорость приложений на «нативных» шаблонах вырастает в 2-3 раза! По-моему, неплохой результат и ради него можно написать пару-тройку лишних символов.

Д ва с лишним года я был ярым сторонником Smarty, но теперь я послал Smarty в пешее эротическое путешествие. Всё, теперь только «нативные» шаблоны: многие вещи в них сделать гораздо легче, чем в каких-либо других шаблонизаторах. Шаблонизатор уровня Smarty — это настоящие грабли!

В замен 300-килобайтному Smarty, я за 10 минут написал свой простенький шаблонизатор. Его задача — собирать переменные в одно место и рендерить шаблоны. И всё! Больше от шаблонизатора ничего не нужно.

В от и всё. Метод xss будет полезен при выводе данных для предотвращения XSS-уязвимости.

П ример использования:

Ф айл шаблона /tpl/index.tpl

П о-моему, всё просто и удобно.

Замечение: «сложности» могут возникнуть с циклами foreach. Из-за бага в PHP. Данная ошибка уже исправлена в версиях PHP выше 5.0.5. Пользователям предыдущих версий просто придется писать:

Автор: Анатолий Ларин.

Комментарии:

Patrick

Ну если есть у клиента свой сервак или на худой конец VDS и еть потребность в шаблонизаторе, то Blitz. Хотя сам php является шаблонизатором :)

larin
Patrick
?, какая такая потребность? На фига?

Patrick

Толь, ты не всегда будешь разрабатывать проекты один и не всегда верстальщики буду знать php….

larin
Я найду такого, который знает. =)

Patrick

Не всегда будешь фрилансером ;)

larin
Конечно, не всегда. Когда-нить буду богатым фрилансером =)))

FX Poster
Мдя. Smarty хорош тем, что его шаблонный движок реально заточен под использование верстальщиками. :)
Пример: <$smarty.now|date_format:”%Y-%m-%d %H:%M:%S”>. Красиво, удобно.
По поводу своего View:
а почему не взять Zend_View? :)

поменяй на __set
Я бы переменную класса $_template вообще убрал. Это View, ему пофиг что рендерить, название файла в нем содержаться не должно. Да и к тому же – у тебя эта переменная в одной функции юзается. Я бы переделал так:

Зачем render делать – подумай на досуге. ;)
_strip можно бы было вынести в дополнительные плагины. Ну вообще – это я уже придираюсь. :) Посмотри на реализацию Zend_View на досуге.

FX Poster
Млин. Лучше бы оставил возможность свой html в комментах писать.

Patrick

__set, __get и другую магию я бы не использовал…

вот мой рендер…
А вообще неплохое разделения на дисплэй и рендер. Рендер по сути должен из щаблона, сделать Html(без вывода), например для Кэша всей страницы….

FX Poster
__set, __get и другую магию я бы не использовал…
И почему-же? )
На самом деле – с выводом рендер или без вывода – неважно. С ob_* всегда переделать можно.
Отдельную функцию для рендера делать можно и нужно чтобы полностью инкапсулировать тот файл, который мы include’им от локальных переменных.

Здесь у нас в шаблоне будут доступны еще и переменные $template и $strip. Мелочь, но неприятно. ;)
Patrick

У тебя с темлейтами тот же бок. :) View и сами шаблоны находятся на разных уровнях программы. Хранить одно в другом – неправильно.

FX Poster
Да, и еще – по поводу смарти. Это же не только шаблонный движок. ;)
Hint: про кеширование в смарти почитай как-нить.

larin
FX Poster, ты думаешь я не читал, за 2-то года? =)))
Детские шалости все это, все равно он тормоз полный, и кэширование там слабенькое и неуклюжее.

larin
[offtop]Блин, достал этот WP! Мой вчерашний комментарий, просто исчез… у кого-нить такое было?[/offtop]

larin
FX Poster,
кажется твоя функция render() не подходит к моему примеру. Как я понял, данная функция не является методом класса VIEW_View, иначе введение не имеет смысла. Но при таком подходе функция render() ничего не знает о классе и мы получаем:
Fatal error: Using $this when not in object context in …/index.tpl on line 7

FX Poster
Как я понял, данная функция не является методом класса VIEW_View
Является ;)

larin
А смысл тогда. В ней так же доступны все свойства класса. И никакой инкапсуляции…

FX Poster
Шаблон:

Попробуй “выполнить” его в своем классе.
Я имею ввиду, что в твоем классе локальные переменные функции внутри шаблона также будут видны. А это плохо.


larin
Но у меня нет в шаблоне такого доступа. Все переменные в шаблоне у меня начинаются с $this.
Смысл, конечно есть, но ИМХО, не большой, т.к. это все рано не защитит нас от вызова свойств класса:

FX Poster
Я не знаю, может я плохой программер, но меня постоянно так и тянет написать переменную без $this. :)
По поводу
Этого тоже можно избежать. Отнаследовавшись от твоего класса. В наследнике такой проблемы уже не будет.

larin
>>> Я не знаю, может я плохой программер, но меня постоянно так и тянет написать переменную без $this. :)
Нет, скорее ты ленивый программер.
>>> Этого тоже можно избежать. Отнаследовавшись от твоего класса. В наследнике такой проблемы уже не будет.
Точно! =) Ты прав, но мне как-то лень… на фик это. Я это делаю только для себя и пока для одного проекта. И в шаблоне мне явно не стукнет вызывать переменные начинающиеся с “_”.
А на счет наследования, верно. Класс View можно сделать абстрактным – абстрактным будет метод display() (+ можно добавить абстрактный метод fetch()), а от него уже наследовать классы: Html, Pdf, Rtf и т.д.

Patrick
View и сами шаблоны находятся на разных уровнях программы.
Поясни…
__set, __get и другую магию я бы не использовал…
И почему-же? )

вся эта магия только замедляет программу!

FX Poster
Patrick
Поясни…
Скажем так – считай View менеджером по работе с шаблонами. Ему пофиг, какой шаблон он будет обрабатывать. Он их все обрабатывает одинаково – следовательно хранить шаблон во View – неправильно.
Разные уровни программы – имеется ввиду, что понятие шаблон и вью напрямую не связаны. Client работает c View и Client работает с шаблоном (ну или с названием файла шаблона), и Client-же передает во View сам шаблон.

FX Poster
вся эта магия только замедляет программу!
Вот вы так говорите – долго, медленно, плохо. На самом деле обращения к той же бд будут занимать гораздо больше времени, чем php запустит функцию __get/__set. Я ни разу не встречал программы, в которой отказ от __get/__set или подобных функций (направленных на удобство программиста) реально сказывался на ее быстродействии. Т.е. если у тебя прога с такими функциями реально тупит, то и без них лучше не станет. Лучше ими пользоваться в полной мере, а в свободное время читать про реальные возможности рефакторинга. Благо – PHP такой [дебильный] язык, что тут можно рефакторить и рефакторить. Одно только различие в производительности $a[a] и $a[‘a’] чего стоит.

larin
>>> Я ни разу не встречал программы, в которой отказ от __get/__set или подобных функций (направленных на удобство программиста) реально сказывался на ее быстродействии.
FX Poster, зачет! Просто 5 баллов! Как говорится: экономия на спичках. Меня Patrick
не слушает, может к тебе прислушается =)

Patrick
Admin
Лень писать тесты… C include/require тебе пример привел…

FX Poster
Да нафиг тесты. Хочешь быстрее – юзай Си. Хочешь удобнее – юзай скриптовые языки. Юзать скриптовые языки и заморачиваться на синтаксисе (типа если мы напишем так – будет быстрее, чем если мы напишем по-другому) – в общем случае бред. Лучше позаморачиваться над хорошими алгоритмами. ;)
PS. В случае PHP – все же иногда позаморачиваться стоит – см. выше мой пример с индексами в массивах. Но в общем случае – это действительно бред.

FX Poster
Можешь мне не верить, но тебе это говорит человек, хорошо знающий C++ и умеющий оптимизировать программу не только с помощью оптимизаторов компилятора.

Sam
Неужели вы за 3 года не научились его правильно готовить?!
Как он может быть медленней, если шаблон не парсится каждый раз? Вы открывали когда-нибудь скомпилированные темплейты?

larin
Sam,
>>> Неужели вы за 3 года не научились его правильно готовить?!
Научился, и хорошо =) Но все же это костыли. Зачем писать на псевдоязыке, что б потом это все переводилось обратно в PHP? Это модно?
>>> Как он может быть медленней, если шаблон не парсится каждый раз? Вы открывали когда-нибудь скомпилированные темплейты?
Конечно смотрел…
Но я еще не только смотрел но и тестировал. Один и тот же проект я сделал и на Smarty и на своем шаблонизаторе – итог описан в этой статье.
То, что Smarty тормоз, я взял не с потолка, я это доказал на практике.

Sam
>>> В 2-3 раза
Это догадки, а не результаты тестов.

larin
Это не догадки, это реальные цифры.
Я их замерял.
На одной и той же машине. Один и тот же сайт. Один и тот же набор данных.
Так, что не нужно так заявлять.

Sam
Ну, обычно результаты тестов приводятся в миллисекундах. При этом тестирование должно проводится не разовым запуском, а как минимум apache bench или, как его ещё зовут, ab. Ну и, наверное, нет смысла говорить, что тестирование на страничках вроде “hello world” не в счёт т.к. не показывает ровным счётом ничего.

larin
Я тестировал при помощи ab. Правда, на Win-машине.
Я еще раз повторяю, что тестирование проходило на реальном сайте. Совсем не похожем на “hello world” =)))
Когда тестировал, я не собирался это никуда выкладывать… поэтому не сохранил данные из ab. Но я помню, что данные отличались в 2-3 раза.
Но если такой интерес есть, на днях я сделаю новые тесты и выложу данные в миллисекундах.

Sam
Будет очень интересно.

Patrick
Sam получите распешитесь ***

larin
Patrick, спасибо! =)
Тут данные уж совсем не в пользу Smarty, не в пользу аж в 4,5 раза!

CyberFox
Тема актуальная. Лично я использую Smarty, но предложенный код попробую. Может и у меня сообщения по этому поводу появятся.

larin
CyberFox
Попробуй.
И жду конструктивных комментариев =)

Sam
Спасибо. Поигрался. Жаль исходного кода теста нет :(
Выводы: при первой генерации шаблона Smarty действительно значительно отстаёт от нативных шаблонов, но обгоняет почти все остальные шаблонизаторы.
При повторном запуске Smarty занимает законное третье место:
1 php 0.000527 100%
2 php_templates 0.001863 354%
3 smarty 0.002531 480%
Не такое уж серьёзное отставание от php_templates, который, кстати, является pecl-расширением.
А если учесть что время генерации мало, пользователь будет ждать отнюдь не генерации страницы, а загрузки сгенерированной разметки.

DM
>Зачем писать на псевдоязыке, что б потом это все переводилось обратно в PHP? Это модно?
Ах да, нужно писать сразу в машинных кодах. Это модно.
Кеширование в смарти может сохранять шаблоны на смарти в шаблоны на РНР, в которые лучше не заглядывать. Оно работает? Работает. Работает быстро. Только в отличие от приведенного выше варианта работает процедурно а не объектно.
А кроме того можно еще поцепить опкодкешер и ZendOptimizer. И я не вижу разницы.

Sam
DM, это не кэширование, а компиляция. Кэширование там тоже есть.

DM
Да, пардон. Именно компиляцию имел ввиду.

larin
Sam,
>>> Спасибо. Поигрался. Жаль исходного кода теста нет :(
Таким образом, я думаю, могу не писать заново Smarty-шаблоны (т.к. после тестов они были удалены). Все и так ясно =)
To: all
Но даже при повторном запуске уже “откомпилированных” шаблонов Smarty проигрывает, и довольно сильно в скорости. Это видно из тестов и с этим согласился, наконец, Sam =)
To: DM
>>> Ах да, нужно писать сразу в машинных кодах. Это модно.
Зачем же так сразу… во всем нужно знать меру. :)
А кроме того можно еще поцепить опкодкешер и ZendOptimizer. И я не вижу разницы.
Не видите разницы? А если тоже самое сделать при нативных шаблонах? Не будет ли скорость больше?! :)
А вообще, я никого не собираюсь обращать в “свою веру”. Я думаю, каждый выбирает то, что ему более удобно и более полно подходит под определенную ситуацию. Скажу лишь, что Smarty не подходит для проектов с большой нагрузкой (хотя бы 300 000 хитов в сутки). Конечно можно поставить сервак мощнее, но стоит ли? Может проще для данного проекта отказаться от Smarty?

Sam
Но вы хоть согласны, что из всех построеных на php шаблонных движков Smarty является как самым быстрым, так и самым удобным?

DM
Насчет 300 000 хитов в сутки скоро проверим ;)
Сразу и ZendFramework с ним же =) Результаты у меня в блоге будут.

larin
Sam, конечно согласен!
Самым удобным, самым распространенным и самым быстрым (если брать движки написанные на PHP).
Я ж поэтому им и пользовался почти 3 года =)
DM, вы делаете крупный проект на ZF & Smarty?
Можно узнать на каком железе это будет работать и на какую нагрузку вы расчитываете?

Александр
Помойму на некотором этапе веб разработчик должен прозреть и понять, что процесс и скорость разработки/внедрения гораздо важнее, чем скорость шаблонизатора. тем более железо на сервере всегда можно наростить, а людского времени никогда не хватает и не поддается существенной прокачки.

Sam
Согласен. И особенно это актуально как раз для больших проектов. Тут важен баланс между удобством и производительностью. Как по мне – Smarty – золотая середина.
p.s. что ZF золотая середина сказать не могу…

larin
Александр, полностью с вами согласен. Но есть одно НО, мне все равно какие шаблоны писать Smarty || нативные… скорость разработки от этого не страдает.

Patrick
DM, судя то тестам ZF не самый быстрый Framework…. ИХМО я бы не стал его использовать в таких проектах…
Smarty является как самым быстрым
помоему WACT быстрее, да и больше функциональности у него…..
процесс и скорость разработки/внедрения гораздо важнее, чем скорость шаблонизатора
Переход на нативные шаблоны занимает час, с учётом написания класса

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

dkrnl
*** – Expose, a powerful PHP template engine.
движок на аснове pure-php, вообщем все хорошее уже придуманно.


Sam
€ 49 как-то не хочется за него отдавать.

larin
>>>А сколько времени занимает обучение php дизайнера/верстальщика?
А если сам программист занимается верской, что бывает кстати довольно часто? :)
>>> Вообще если учесть специфику MVC, то шаблонизатор должен как можно меньше позволять.
Думаю многие с вами не согласятся :)

larin
€ 49, за то, что можно написать за 15 мин?
А если там есть навороты, так они в движке не нужны ))

Илон Маск рекомендует:  Что такое код enumfonts

Patrick
А сколько времени занимает обучение php дизайнера/верстальщика? А исравления ошибок за ними, поскольку сам шаблон на php дает большие возможности, а руки у творческих людей чешутся всегда?
Отвечу вопросом на вопрос. А сколько на Smarty.
Вообще если учесть специфику MVC, то шаблонизатор должен как можно меньше позволять.
наворотов в Smarty предостаточно… мне интересно причём тут шаблонизатор и MVC, разве Veiw переводится как шаблонизатор.

Sam
Если посмотреть внимательно, € 49 берут не за просто так.

Александр
А если сам программист занимается верской, что бывает кстати довольно часто? :
к счастью не всегда так:) но и программисты тоже люди.
Отвечу вопросом на вопрос. А сколько на Smarty.
Меньше чем для php. Но хотелось бы ещё меньше.
наворотов в Smarty предостаточно… мне интересно причём тут шаблонизатор и MVC, разве Veiw переводится как шаблонизатор.
View подразумевает презентацию, она в конечном итоге осуществляется через тот или иной шаблонизатор.

larin
Александр,
>>>к счастью не всегда так:) но и программисты тоже люди.
Фраза, по-моему, подразумевает, что PHP-шаблоны намного сложнее Smarty-шаблонов… разве это так. Да, программисты тоже люди (хотя и не всегда :) ) и при том ленивые люди (в большинстве), но какая разница писать: <$title>или (либо )?
Зато если нужна в шаблоне какая-то промежуточная переменная, не нужно громоздить конструкции типа:
, достаточно написать $name=’Bob’. Ведь программист тоже человек =)

Patrick
View подразумевает презентацию, она в конечном итоге осуществляется через тот или иной шаблонизатор.
Класса Анатолия(у меня кстати прмерно такой же), трудно назвать шаблонизатором….

Александр
Зато если нужна в шаблоне какая-то промежуточная переменная, не нужно громоздить конструкции типа:
php слишком много дает свободы. а от этого может пострадать разделение бизнес логики от представления
Класса Анатолия(у меня кстати прмерно такой же), трудно назвать шаблонизатором….
ну тогда давай называть шаблонизатором то, что соединяет данные и представление(html,pdf,xml,text и т.п.)

Patrick
Меньше чем для php. Но хотелось бы ещё меньше.
циклы, операторы вывода, присвоение переменных, ветвление, +

20-30 функций намного быстрей выучить чем Smarty.

Александр
>>>циклы, операторы вывода, присвоение переменных, ветвление, +

20-30 функций намного быстрей выучить чем Smarty.
если бы всё было так просто, то наверно шаблонизаторами никто и не пользовался.

Patrick
php слишком много дает свободы. а от этого может пострадать разделение бизнес логики от представления
свобода говорите? а теперь взглянем на Smarty.
, – это вообще жесть!, , Модификаторы переменных, плагины. так что свободы в Smarty хоть отбавляй!
если бы всё было так просто, то наверно шаблонизаторами никто и не пользовался.
ну по крайней мере не сложней…

Александр
свобода говорите? а теперь взглянем на Smarty.
, – это вообще жесть!, , Модификаторы переменных, плагины. так что свободы в Smarty хоть отбавляй!

Я Smarty не защищаю, а говорю вообще о проблеме шаблонизаторов. То что S дает хоть какую-то абстракцию уже хорошо.

larin
Александр, немного не понял вашу фразу: “…если бы всё было так просто, то наверно шаблонизаторами никто и не пользовался.”
Что вы имели в виду?
Я Smarty не защищаю…
А было похоже на то. :) :) :)

Смирнов Сергей
Спасибо большое за статью. Всегда знал, что Smarty несет в себе какое-то большое недоразумение:) Использую пассивные шаблонизаторы получается хорошо и без геморра.
Правда, у Smarty есть плюс: кеширование. Хотя, это как посмотреть…

Patrick
Правда, у Smarty есть плюс: кеширование. Хотя, это как посмотреть…
ИХМО кэширование должно проиходить не средствами шаблонизатора….Кэшироваться должны только “чистые” данные.
Банальный пример у тебя блок с html к кэше, закзчик поменял диз, кэш вернулся со старым html.

larin
Смирнов Сергей, пожалуйста.
В Smarty дохленькое кэширование, так что это не плюс.
Согласен с Patrick‘ом кэшировать нужно чистые данные, а не вывод. Это позволяет использовать кэширование более гибко и стоить системы которые не раздражают пользователей своими “зависаниями”. Для динамичных сайтов, где есть куча рейтингов, подсчет пользовательских баллов и.т. кеширование html-вывода не подойдет – оно просто не будет давать прироста в скорости.

Кирпичшн-Вунтру
Неужели, вы правда считаете, что прелесть смарти только в том чтобы забить переменные в массив, а затем их вывести? Если так, то мои соболезнования :)

larin
Кирпичшн-Вунтру, поделитесь с нами своими соображениями. Спасите наши умы =)
Я думаю, все с удовольствием выслушают, ваш рассказ о правильном использовании Smarty.

Артём Курапов
1.Синтаксис ?= (ёлки палки, у вас режутся обычные начала тэгов) хуже читается чем <
2.Кэширование данных у вас как я так понял отсутсвует
3.Архитектура MVC подразумевает что все данные во View попадают из Controller-а, а вы уверены что у вас не возникнет соблазна во view начать использовать глобальные переменные? Аналогично чёрная сторона в smarty использовать .
4.Как тут уже говорили, что-бы движок стал реальным мало плюсов, надо что-бы им пользовались, тогда можно сотрудничать с другими разработчиками.

larin
Артём Курапов,
Артем, что вы имели в виду пож загадочной фразой: (ёлки палки, у вас режутся обычные начала тэгов)?
>>> Кэширование данных у вас как я так понял отсутсвует
Кэширование данных – это дело не шаблонизатора. Кэшированием у меня занимается отдельный модуль. Об этом я расскажу позднее.
По поводу 3-го пункта… какой-то он туманный, при чем здесь шаблонизатор? Здесь все зависит от вменяемости программиста.
По поводу четвертого: я никому не говорил, что мой класс – это реальный движок =), по моему, чтоб что-то было реальным: 1) Оно должно работать; 2) оно должно быть удобно тому программисту, который с этим работает.
Мне удобно в данное время работать с моим простеньким шаблонизатором. А от Smarty я отказался из-за его скорости (читайте выше), и для меня нет никакой разницы в удобстве чтения: <$title>или (либо )
Каждому свое… на вкус и цвет, все фломастеры разные. :)

LARIN » Архив блога » Скажи кэшированию… иногда :)
[. ] я писал статью о Smaty, я не думал, что она вызовет столько внимания со [. ]

Артём Курапов
Насчёт тэгов – поставил открывающий тэг php тут и комментарий обрезался дальше.. наверно его надо в html entity энкодить при показе, иначе он считается тэгом.. хотя я не эксперементировал.
Насчёт кэширования в принипе да, это надо делать отдельно, тем более если memcached есть и используется.
Про синтаксис это пожалуй самое главное. Я видел сайты написанные как сплошной php/html и даже с разделением логики на Controller-View (нечто типа theme в Joomla), впечатление было неприятное. Просто глаз не в состоянии быстро распознать хтмл тэги от пхп и приходится напрягаться просто что-бы понять где переменные а где оформление, я уж не говорю если замешаны вложенные if-else или циклы с объектами.
Smarty всё-таки ограничивает своим псевдо-языком возможности разработчика по использованию как сложных структур так и глобальных переменных. Всё что небыло передано напрямую через assign просто не существует. Эту чёткость потока данных я и имел ввиду под искушением использовать глобальные переменные.
Просто архитектура потока может быть древоподобной, либо как сеть, где всюду используется общие ресурсы – функции, переменные. И в последней архитектуре разбираться сложней новичку.

larin
Артём Курапов,
Насчёт тэгов – поставил открывающий тэг php тут и комментарий обрезался дальше.. наверно его надо в html entity энкодить при показе, иначе он считается тэгом.. хотя я не эксперементировал.
Странно. Хотя я тоже не экспериментировал – нет времени ))) Попробуйте конструкцию
На счет того, что глазу сложно привыкнуть к синтаксису – так это зависит от редактора и от привычки. Всему нужно учиться и к некоторому нужно привыкнуть (кто-то привык к Windows, кто-то к Linux, а кому и MacOS душу греет :) )
В общем, я пришел к выводу, что каждый выбирает то, что ему больше нравиться и подходит для данной ситуации.
Я для себя выбор сделал. Поделился этим с вами, но я не заставляю вас идти по моему пути. Я просто показал еще одну тропинку, не мною открытую, но я по ней иду. :)
Как я уже говорил, Smarty “рулит” для клиентских приложений с небольшой нагрузкой, когда идет разделение труда программист-верстальщик.
Но для приложений где важна скорость, ИМХО, Smarty неповоротливый монстр. Без которого с легкостью можно обойтись.

cyberfox
Я тут посмотрел пример в действии (нашел наконец время 4:16 утра :) ) и меня это натолкнуло на мысль:
такой подход дает большую гибкость при построенни разного рода “движков”.
Если система документирована и входные/выходные данные и их форматы описаны и определены, то проблем особо не должно возникнуть для верстальщика шаблона.

Sam
Ну, это да…

larin
cyberfox, спасибо что нашел время, тем более такое оригинальное – 4 утра =)
А как ты смотрел его в действии? Применил в каком-то проекте?

cyberfox
Пока что нет, но возможно сайт Smolensk Linux User Group будет использовать эту фичу (но пока что он на Smarty).
Ближе к утру ознакомился с Zend Framework, наталкнуло на мысли, особенно когда нашел посто о сравнении производительности MCV фреймворков:
http://www.alrond.com/ru/2007/feb/04/dopolnenie-k-test-mvc-frameworks/

larin
На какие мысли?

Sam
Ну, какие тут могут быть мысли? Питон с Django делает всё и вся с большим отрывом и при этом довольно-таки стройный и продуманый.
На php, к сожалению, чем стройней, тем медленней. Внутренности CodeIgniter – это просто жесть, но работает он очень даже быстро, что наводит на мысль, что так и задумано…

Sylvio
в функции _strip забыты обратные слеши у спецсипмолов

larin
в функции _strip забыты обратные слеши у спецсипмолов
Ой, точно! И за столько комментов никто не заметил…
Они не забыты, это просто при вставке их WP порезал… Сейчас попробую поправить, хотя после такого количества пива не обещаю ))))
Sylvio, спасибо за внимательность! Поправил.


Яремчук Роман
Браво!- За замечательную статью.

larin
Яремчук Роман:
Браво!- За замечательную статью.
Спасибо. :))) Никак не ожидал столь высокой оценки ))
Да и такого количества комментариев не ожидал.

Sam
Главное – вовремя затеять спор ;)

larin
Sam:
Главное – вовремя затеять спор ;)
Я ж нечаянно. =)))
Кстати на счет спора. Интересный спор получился на тему кэширования. Присоединяйтесь пожалуйста, а то нам вдвоем с vasa_c довольно сложно подытожить тему.

bananos
Мда, начал читать и было подумал что автору наконец пришла в голову очевидная мысль, но после фразы
“за 10 минут написал свой простенький шаблонизатор” я разочаровался…
php сам по себе шаблонизатор, не надо изобретать велосипедов

larin
bananos
php сам по себе шаблонизатор, не надо изобретать велосипедов
=) А я разве говорил другое. Вы не так поняли мою фразу: “за 10 минут написал свой простенький шаблонизатор”
Эта статья, как раз и была написана в защиту того, что PHP сам по себе прекрасный шаблонизатор.
Почитайте статью еще раз, а так же обратите внимание на комментарии

Patrick
“за 10 минут написал свой простенький шаблонизатор” я разочаровался…
В чём?
и что вы используете в качёстве View?

Sam
class VIEW_View :)

larin
Sam
class VIEW_View :)
В каком смысле? Вы используете в проектах мой VIEW_View? Или что? :)
bananos, куда вы пропали? Я по прежнему жду вашего ответа, на вопросы Patrick‘а.

Sam
Я про то, что все нормальные самописные шаблонизаторы похожи на class VIEW_View. Мой правда уже оброс неслабо… Layout-ы, хэлперы и т.д. Но смысл тот же.
Не думаю, что bananos придумал что-то очень уж отличающееся.

Patrick
Sam Хэлперы это из “другой” оперы…. Не думаю что лучшем решением будет напрямую включать их во View.

Sam
Почему же? Это довольно распросранённая и удобная практика. См. CakePHP, CodeIgniter.

Zend Framework: дорабатываем Zend_View
[. ] очень похож на ряд велосипедов включая мой: HSTamplate, Прощай Smarty или простой шаблонизатор, Шаблонизировать за 6 секунд (и 6 строк) [. ]

Stan
Может, я чё не то делаю, но при запуске тестовой странички из твоих примеров меня сразу выкидывают с грязными ругательствами: Parse error: parse error, unexpected T_STRING, expecting T_OLD_FUNCTION or T_FUNCTION or T_VAR or ‘>’ in z:\home\localhost\www\class.view.php on line 4
Не силен в php, что там ему не нравится во фразе private $_path; ? Может, у меня версия php не правильная?

Sam
Stan
У тебя случаем не PHP4?

Stan
Да, он самый – 4.4.4 кажись. В помойку? На пятый пора переходить?

Sam
Пора. Четвёрка официально больше не поддерживается.

Stan
У моего хостера тоже 4.4.4, облом :) Ладно, поставил я себе php5, запускаю – оппа! Что-то не нравится ему в строке $view = new View(‘/tpl/’); Говорит, что Fatal error: Class ‘View’ not found в этой строке. Может, опять что-то не хватает? :)

Sam
$view = new VIEW_View(’/tpl/’);

larin
@Sam, большое спасибо за помощь! =)))
@Stan, будь чуть внимательнее, а если, что пиши поможем. =)

Staglu
Не плохая сатья. Я в нете долго искал на подобие такой. Спасибо!!

Никита
Спасибо. Сразу после прочтения стал использовать вышеприведённый класс.
Но нашлось одно НО: информация внутри тэгов и выводится не так, как хотелось бы :(

Никита
Урс… Внутри тэгов: , удобный для просмотра массивов, после передачи через $view->display(‘template’) становится таким: , что не очень удобно для просмотра многомерных массивов.
Также через тоже удобно писать листинги кода и т.д. Но нужно иметь возможность сохранять предусмотренные отступы.

Никита
Блин.
В первом примере код такой:

vasa_c
Какая разница писать: <$title>или (либо )?
Неоднократно поднимал подобный вопрос.
Наиболее распространенный ответ: “а вот разница”.

vasa_c
php-теги обрезались

larin
@vasa_c
И зачем смотреть на тех кто отвечает “а вот разница”.
По моему, они просто хотят похоливарить, и все )
Для вас есть разница писать:
<$title>или ?
З.Ы. Чтоб не резались php- и html-теги вставляйте их между тегами code

Daev
Первый вариант читабельней.

Sam
Так чуть читабельней:

Sam
Блин! Ненавижу этот WP :(

cyberfox
Что-то пост зарос камментами, видимо тема актуальная. Я после знакомства с CakePHP забыл что такое Smarty вообще.

larin
@cyberfox
Конечно, актуальная. Люди наконец начали осознавать, что PHP сам по себе очень мощный шаблонизатор.
И лучше использовать машинные ресурсы на что-либо другое, нежели на перевод с одного псевдоязыка на PHP.
И давно ты работаешь на CakePHP? Уже есть готовые проекты?

cyberfox
Нет, не давно, но успехи небольшие есть. Я нахожусь в данный момент в стадии познания технологии и попутно пеку сайт linux user group со старого движка.

Daev
Мне кажется, что ели уж экономить ресурсы, то надо начинать с отказа от самого php. А раз уж использовать его, то потери на шаблонизатор уже можно не учитывать.


larin
@Daev
Тоже вариант, но какой-то радикальный =)
В принципе, спор затянулся и спорить можно бесконечно, на некоторых проектах нативные шаблоны действительно дают выигрыш в производительности, на некоторых его не заметно.
Но, для себя я точно определил, что Сматри – это ненужный костыль, для PHP.
Сторонники Smarty, могут кидать в меня камни… а может кто-нить из них одумается… а может одумаюсь я =)))
Все может быть.

vasa_c
ping.
из дома ничего не доходит.
Меня забанили? )

larin
vasa_c, конечно нет!
Я рад активным комментаторам

SergiusD
А будет ли прирост производительности если передавать не копии а линки на переменные?
Конечно это добавит ограничения, но хотелось бы знать реальные цифры, стоит или нет.

vasa_c
SergiusD, неа.
***

SergiusD
Подскажите пожалуйста для чего нужна функция
private function _strip($data)
сначала думал что она убирает символы перевода строки и тп в шаблоне, то есть бесполезные с точки зрения html, но потом увидел что слеши экранированные. И зачем двойной пробел заменяеть на пустоту?

larin
SergiusD
Вы все правильно думали
Она убирает символы перевода строки во всех системах (Win, *nix, Mac), плюс убирает двойной пробел и табуляцию, т.к. эти символы так же не существенны для браузера.
Если парой слов – то это функция вытягивает весь HTML-код в одну строку.

Sam
Гм… нехорошо. Тогда уж убирать их только между > и чтобы шаблонизатор потом постоянно перегонял эти
>шаблоны в PHP-код (куча никому не нужной работы. )
Smarty компилирует шаблон в php файл ОДИН раз, потом дергает этот php файл. Кроме того у него есть кеширование, которое если правильно организовать, дает очень неплохие результаты.

dLex
Кто то не доганяет для чего нужен шаблонизатор.
Чтобы пользователи которые имеют право на запись в шаблоны не имели доступа к php. (темы для блогов например) …

Roman
Лично я не навижу PHP перемешанный с HTML и независимо он того кто верстает страницы, дизайнер или программист, котлеты должны бить отдельно а мухи отдельно.
Сила смарти в том что он популярней всех остальных шаблонизаторов, и становится стандартом. Самая главная проблема всех PHP-шников и самый большой недостаток PHP, в том что нет четкой структуры как в яве.
Мне попадаются всякие сайты на доработку и иногда диву даешся какой может быть ламерский код, некоторые начинающие программисты умудряются почесать левой пяткой правое ухо. Реальный пример когда 1500 строчек дикого php кода, которого не в состоянии нормальный человек вникнуть вообще, первращается в 15 строчек и небольшой шаблончик. И самое плохое что большенство так и программирует изобретая велосипед, и тратя недели на то что можно сделать за час, а все потому что нет стандартов.

dLex
Так что Ларин =) учите мат.часть

dLex
Да а эту статью я лучше бы удалил =)

Andrey
dLex, смешно.
Roman, ну покажите мне шаблон на Java, точней на JSP.

larin
@dLex
Вы мне предлогаете учить мат. часть.
=) =) =) =) =) =) =) =) =)

dLex
Что смешного ? =)
не довать доступ к php
А статью удалил бы потому что класс написаный вами не возможно назвать шаблонизатором.
1 Я хочу сначала подгрузить шаблон №1 и выполнить парсер , но отдовать нечего пользователю не буду, потом шаблон №2 и №3
и только потом если все хорошо отдать пользователю =) html
2 ob_start(); ob_get_clean(); – у меня меня просто нет слов
3 $_SERVER[‘DOCUMENT_ROOT’] – отлично будет работать на IIS =)

dLex
ну как с твоим классом 1 вариант вкатит ?

dLex
Короче узай include($tmpl) =)

dLex
Короче это даже не велосипед =) тут колесо причем которое нельзя установить на велосипед =)
Так что Smarty учись настраивать и не грузить все его 300 кб =) и править

dLex
xml xslt – вот в чем сила брат

Sam
dLex
А что не так с ob_start(); ob_get_clean();?

cyberfox
Выскажусь по теме:
Раньше использовал Smarty, но как перешел на cakePHP
необходимость в нем отпала, как и в QuickForm.
Всегда считал, что PHP сам по себе шаблонизатор.

neyron-net
Всем доброго здравия.
В данный момент работаю программистом и верстальщиком, был во фрилансе почти 2 года…
Скажу лишь одну фразу. Smarty – остается Smarty, PHP – остается PHP…
Два колеса не могут крутиться в разных направлениях. Золотая середина появиться лишь тогда когда верстальщик будет знать и Smarty и PHP в равной степени, чтобы разбираться в коде. Ему еще нужно будет думать об кроссбраузерности и многих других вещах, нежели вести споры о “моде”.
____Из личного опыта_____
Всем спасибо. Ах. да. Пост…-Смарти – в топку. Все гениальное просто (Include).

NETMAN
Без нормального кеша твой шаблонизатор для смарти не конкурент.

larin
@NETMAN
Читай статьи дальше, там еще 2 статьи о кеше )))

Большое белечье ушко
последние несколько месяцев стал выносить всю логику из Smarty в php код, быстродействие немного увеличилось. В итоге шаблон содержит только циклы и выводы переменных. Отсюда вывод – для таких целей ну никак не требуется дополнительныё 150кб класс.
Кто видел в каком виде компилируются шаблоны Smarty? Этож полный ахтунг.
Кстати кеширование Smarty не всегда даёт прирост производительности, иногда наоборот замедление.
Циклы одно из узких мест в PHP, поэтому не рекомендую одни и те же данные гонять в разных циклах. Достаточно в одном цикле обработать их и тут же проверстать в блок шаблона.

Pawel W.
Smarty придуман, скорее, для сервисов, в качестве доступа аккаунтов к о*уенным серверным возможностям, чего и требуют аккаунты, но доступ, разумеется, в ограничительных рамках. И как иначе, ты, это сделаешь? Не давать же кому-угодно ковыряться в php-кодах всего сайта?

solo
полная херня написана

Maximus3
Smarty придуман, скорее, для сервисов, в качестве доступа аккаунтов к о*уенным серверным возможностям, чего и требуют аккаунты, но доступ, разумеется, в ограничительных рамках. И как иначе, ты, это сделаешь? Не давать же кому-угодно ковыряться в php-кодах всего сайта?
Это ж надо было такой бред сморозить…

Djinn
Здравствуйте… по моему шаблонизатор совсем не очень…
1) обязательно нужна функция fetch – ибо толку от шаблонизатора такого ?
2) зачем нужен шаблонизатор без кэширования ? можно просто инклудить шаблон, или ты это сделал чтобы переменные не смешивались ?
3) если программист не пишет в шаблоне $this – это большой плюс, а не лень! this вообще нет смысла писать так как ты используешь в шаблоне локальные переменные функции или класа + глобальные переменные, но я их не использую обычно…

Larin
@Djinn
Привет!
1) Функция fetch появилась на следующий день после написания статьи (добавлять было лень)). Я думаю, ее не сложно выделить из метода display, и чуток дописать )
2) Для удобства и структуризации )
3) В принципе, с этим согласен.
Вообще же в свете последнего перехода на Джанго… данный шаблонизатор просто позор на мои седины ) Хотя для того времени было нормально, главное он выполнял все поставленные перед ним задачи (правда, в несколько изменном виде)

Petr
Наткнулся на эту статью… Проблема по поводу шаблонизаторов появилась в начале 07 года. И только вот сейчас я встретил статью, в которой вполне ясно описано.
Какого вы мнения о FastTemplate ? Модная вещь была когда-то.
Вообще же в свете последнего перехода на Джанго… данный шаблонизатор просто позор на мои седины
Почему Django а не RoR ?

Petr
Сколько вам лет, гражданин программист,
и почему предложенный вами шаблонизатор (я б его пользовал только для “2) Для удобства и структуризации )”) спустя два года вы назвали позором.
Хочу его пользовать, так что интересно, что может быть в нём плохого.
Вы пока подумайте, а я скопирую его себе ))

Larin
@Petr
Какого вы мнения о FastTemplate ? Модная вещь была когда-то.
Модная, но не более. По мне Smarty намного лучше ) Но это конечно, субъективно.
Почему Django а не RoR ?
Красота и гибкость языка Python меня покорили ) Так же понравилась сама идеология Django.
Сколько вам лет, гражданин программист,
Об этом лучше умолчать ))))
и почему предложенный вами шаблонизатор (я б его пользовал только для “2) Для удобства и структуризации )”) спустя два года вы назвали позором.
Я постоянно учусь новому, развиваюсь и по новому смотрю на уже привычные вещи. И мой код, написанный, скажем 5 лет назад, иногда вызывает у меня улыбку, а иногда и ужас =)
Хочу его пользовать, так что интересно, что может быть в нём плохого.
Это скорее не шаблонизатор, а некий класс-хранилище )
Да и после Django не могу смотреть на шаблонизаторы без поддержки наследования шаблонов )

phpdude
Я делал вот так:
самое смешное, что это тоже смое, что и
)) ибо \s = [:space:]+\r+\n


MikJager
Я не обломался, все посты прочитал. Вы далеко не уходите от темы. О какой экономии Вы говорите, что значит в два три раза … что это, на 1 или 2 тысячные секунды смарти медленней, и что?! Что это … ужас какая нагрузка, или memory он много съел?! О чём вы говорите, о какой скорости …. конект к БД даёт такой тормоз всей системе, чтобы тысячные доли секунды смарти просто крошка от куска хлеба! Или кто то писал про ZendF … Вам вообще в этой теме делать нечего, тут битва за тысячные секунды, если Вы используете зенд, Вы не догадываетесь наверное, что такое нагрузка на сервак! По поводу нагрузке при нескольких десятков или сот тыс. хостов скажу вот что. Это явно не сайт визитка, наверняка кол-во запросов в БД будет там большое, да и обработка(вывод на том же нативном шаблонизаторе) будет довать существенный тормоз в скорости генерации страницы, один цикл в объемлемом данными массиве чего только стоит, уверен что это может даже не сотые секунды. Тут уже зависит от организации самого сервера! Я не спорь, верстаки не часто лезут что-то менять в шаблонах, но именно в момент создания он облегчает работу. Намного проще натягивать всё это дело.
Не скажу что это экономия на спичках (особенно с кэшированием, но в третий версии даже это было реализованно намного глаже), но это не то место где надо так сильно заботиться об экономии. Можно больше сэкономить на то, что правильно написать код php, более грамотно!
тест на win (средние значения из 100 проб на каждый) соответственно без кэширования!
ZF(db off) – 0.19
CI(db off) – 0.097
My(Db off) – 0.011
———————
ZF(db on) – 0.22
CI(db on) – 0.11
My(Db on) – 0.02
My – это Db Simple(dblab: убранна поддержка драйверов БД) и Smarty 3.

MikJager
ой … забыл не маловажное! И даже очень важное! Это memory!
ZF(db off) – 0.19 (7.8 мб)
CI(db off) – 0.097 (5.3 мб)
My(Db off) – 0.011 (780 кб)
———————
ZF(db on) – 0.22 (9.2 мб)
CI(db on) – 0.11 (6.1 мб)
My(Db on) – 0.02 (990 кб) ну ладно, путь будет 1 mb :)
По поводу оптимизации всегда будет много споров, использование кэширование(разного типа) и акселераторов. Очень много зависит как и от организации самой системы(программы) так и от сервера, и так же имеет фактор такой, как написание самого кода!
и или огого сколько
вот даже в такой сказалось ситуации можно выиграть огого сколько

Larin
Привет, Мик!
С момента написания статьи прошло более 2-х лет, и по прошествии этого времени я уже могу сказать – данный шаблонизатор не удобен ))) По правде говоря он вообще шаблонизатором не является, это просто класс-контейнер с данными и методами для работы с этими данными.
Но! На тот момент на одном из проектов данный подход действительно давал выигрыш и по времени, и по памяти.
Проект не использовал ни ZF, ни других сторонних FW. FW был свой, с минимумом слоев абстракции, максимально рассчитанный на быструю работу.
Но сейчас условия изменились и иногда бывает проще поставить еще один сервер, но работать с удобным шаблонизатором.
Опять же, все зависит от задачи!

MikJager
Ой пардон! дату поста не усмотрел) Конечно же, задачи и ставят определённые рамки в использование того или иного подхода(с тем же шаблонизатором). Просто если встречаются какие то недостатки или чего то не хватает, я думаю не трудно дополнить или изменить. В особенности со Smarty, у меня написаны множество модификаторов и функций, которые приводят выходящие данные к приятному виду. И с каждым проектом эти модификаторы постоянно пополняются. Просто объектно-ориентировочный подход уже даёт снижение производительности, но это снижение не ни что, по сравнению с тем, какие преимущества выходят при использование этого подхода. Smarty по моему мнению оптимальный вариант из ряда шаблонизаторов, который можно легко расширять под свои нужды(задачи) без особых проблем.
Хотелось бы чтобы те, кто не прочитал все комменты :) к посту, не сделали вывод, что Smarty это плохое решение. И не сказать что тут дело вкуса, скорее дело в правильной и обоснованной оценки при выборе того или иного решения.
Спасибо за пост Larin! Приятно было почитать всю эту дискуссию, хоть и времени ушло многовато :)

Larin
MikJager, пожалуйста!
Приятно, то мои посты приносят людям хоть какую-то пользу )

yura
Нормальный ман взял бы и написал….
а то ищете как поднять производительность….
какая нахрен производительность если всё методом тыка проверяется….

Levik
Мегадискуссия :)
В проектах, где к коду шаблонов должны иметь доступ “верстальщики” использование шаблонов считаю более-менее оправданным..
В основном же склоняюсь к php-”шаблонам” + при необходимости – кэшированию (естественно, разумному).
PS. спасибо автору за статью, всем комментаторам – за активное обсуждение :) Хотя, позиция некоторых мне мягко говоря не близка…

Larin
Приятно видеть, что при перепосте на других сайтах, дают ссылку на автора. =)

zlodeyev
SMARTY фуфло и говно засерающее код! Когда открываю проеты написаны на нем , будто в общественный туалет сходил. Только моск прованялся ибо пришлось разбираться в нем. SMARTY это для лохов типа я дизайнер и росту до программиста.
голый PHP это сила, организовать кеширование да и будет с Вами сила джадая, да и OOP редко когда себя оправдывает, господа.

Fghfghj
а сделать сайт который влазит в 1280 на 1024 слабо? даж читать не стал. надо думать о пользователях

coder
zlodeyev убейся ап стену, не знаешь ооп просто молчи

Поделись ссылкой на Seoded.ru с друзьями, знакомыми и собеседниками в соцсетях и на форумах! А сам сайт добавь в закладки ! Так победим.

Поделиться ссылкой на эту страницу в:

АйТи бубен

Инструменты пользователя

Инструменты сайта

Содержание

Шаблонизаторы для PHP

Язык PHP сам по себе может использоваться как шаблонизатор: Изолирование от HTML (смешанный режим) . Недостатком PHP, как шаблонизатора является его многословность, например при экранировании вывода данных.

Различают активные (pull) и пассивные (push) шаблоны.

Активный шаблон, работает как независимая программа со своими собственными операторами, циклами, командами подгрузки содержимого из других файлов и т.д.. Для дизайнера это выглядит сложно. Поэтому обычно для упрощения синтаксиса активных шаблонов инструкции PHP (foreach, if и.д.) «маскируют» специальными псевдотегами. В дальнейшем активный шаблон специальным скриптом- транслятором переводится в обычный код на PHP, который в дальнейшем и выполняется. Недостаток активных шаблонов, что их как правило напрямую нельзя открывать в браузере — будет просто видна мешанина символов, даже если шаблон сохранен в файле HTML .

Пассивные шаблоны не включают никаких исполняемых инструкций. Пассивные шаблоны удобны когда мало блоков и много статического HTML кода.

Шаблонизаторы — трансляторы активных шаблонов.

Шаблонизаторы — для пассивных шаблонов.

Изолирование от HTML

Если вы создаете заголовок страницы динамически с помощью PHP, затем идет статическое содержание страницы и все заканчивается динамически создаваемым футером, можно сделать так:

Более того, PHP- код продолжает выполняться с того места, на котором он оборвался, так что можно его разрывать даже так:

Еще один мини шаблонизатор на php

У меня на работе появилась задачка сделать небольшой проект, для простого просмотра картинок из папок локальной сети.. И как то так само собой сложилось, что я написал вот такой класс для рендеринга видов ( просто я люблю Yii2 да и вообще MVC ). Вот решил поделиться и спросить у занющих людей насколько рабочим в реальных проектах был бы этот класс. Возможно ли решить задачу по другому?? Просто это первое что пришло в голову и есть сомнения в качестве.

Реализацию yii2 рендеринга не смотрел, так как само как то получилось. но посмотрю как нибудь обязательно.

Еще дополню, в проекте не использовался вообще никакой фреймворк. просто приложение на PHP.

После знакомства с Yii рендерингом заменил все таки eval на require, потому что так получается на одну строку меньше =)

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

Хочется заметить, что теперь есть два способа рендеринга отедельных файлов, либо делать это из вызывающего кода методом Renderer::file() либо из кода шаблона методом Renderer::renderPartial().

При использовании этого класса в контроллере или роутере можно использовать вот такой код

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL