$48.41


$944.32


$26.74


Smarty – не просто шаблоны

Вступление

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

Часто, говоря о Smarty, незаслуженно обвиняют его в низкой производительности и «тормознутости», что ж – автор данного материала с указанными товарищами не согласен. Напротив, раз уж мы приняли решение использовать в своем приложении эту библиотеку, я предлагаю вам на полную катушку задействовать ее возможности, отдав на откуп шаблонизатору как вывод информации пользователю, так и управление этой информацией.


Компонентная модель

Одна из сильных сторон Smarty – это возможность создавать свои плагины и расширения. Воспользуемся этой его возможностью в полной мере и попробуем реализовать на ее основе компонентную модель сайта.

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


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

В результате сайт будет состоять из ядра — набора библиотек (классов), которые содержат в себе какие-то низкоуровневые действия, например работают с базой, – и компоненты, которые подключают эти библиотеки и, в нужном порядке, вызывают те или иные их методы.

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

Это основные преимущества данного подхода.

Общие классы

Безусловно, в каждом приложении есть набор классов, которые нужны всем, или большинству компонентов, например, класс для работы с базой. Как поступить в таком случае? И для этой проблемы в Smarty есть удачное решение. Впрочем, давайте по порядку.

Сначала инициализируем класс Smarty:<?php
/** Путь до Smarty */
define ( «SMARTY_DIR» , «/smarty/» );

/** Путь до Smarty шаблонов */
define ( «TEMPLATES» , «/templates/» );

/** Путь до Smarty компилированных шаблонов */
define ( «TEMPLATES_C» , «/templates_c/» );

require_once( SMARTY_DIR . «Smarty.class.php» );
$smarty = new Smarty;
$smarty -> compile_check = TRUE;
$smarty -> force_compile = TRUE;
$smarty -> template_dir = TEMPLATES;
$smarty -> compile_dir = TEMPLATES_C;
$smarty -> plugins_dir [] = LIBS_PATH;
$smarty -> caching = FALSE;
?>

Итак, Smarty готов к работе. Что необходимо сделать с общими классами, чтобы обеспечить доступ к ним внутри любого компонента?

Скажем, у нас есть несколько общих компонентов:
adodb – класс для работы с базой;
session – класс для работы с сессиями;
errors – класс для обработки ошибок;
variables – класс для хранения и обработки состояния массивов $_GET и $_POST.

Первым делом, нам необходимо создать объекты данных классов (параметры конструкторов зависят от вашей конкретной реализации). В целом, это делается стандартным образом:<?php
require_once( CLASSES_DIR . «/variables.class.php» );
$vars = new Variables ();

require_once( CLASSES_DIR . «/errors.class.php» );
$errors = new Errors ( $smarty );

require_once( CLASSES_DIR . «/security.class.php» );
$security = new Security ( $adodb );

// и так далее...
?>

Объекты созданы и теперь необходимо обеспечить доступ к ним в любом компоненте нашего приложения. Для этого необходимо зарегистрировать данные объекты в Smarty:<?php
$smarty -> register_object ( «adodb» , $adodb );

$smarty -> register_object ( «vars» , $vars );

$smarty -> register_object ( «errors» , $errors );

$smarty -> register_object ( «security» , $security );
?>

Для регистрации объектов мы используем метод Smartyregister_object(). После чего ваш объект станет доступным везде, где он может понадобиться. Как «достать» нужный вам зарегистрированный объект мы рассмотрим в следующей части.

Функция «Компонент»

К текущему моменту Smarty ничего не знает о каких-либо компонентах, и нам нам надо научить его работать с ними. Для этого мы добавляем к синтаксису шаблонов новый тег – {component}. Чтобы Smarty научился обрабатывать этот тег – пишем простую функцию:<?php
// Smarty function Component
//
// @author Feskov Kuzma

function smarty_function_component ( $params , & $smarty ) {
$adodb = & $smarty -> get_registered_object ( «adodb» );
$vars = & $smarty -> get_registered_object ( «vars» );
$errors = & $smarty -> get_registered_object ( «errors» );
$security = & $smarty -> get_registered_object ( «security» );

if (empty( $params [ «name» ])) {
$params [ «name» ] = «site_view»;
}
if ( is_file ( ADMIN_LIBS_PATH . «/» . $params [ «name» ] . «.component.php» )) {
require( ADMIN_LIBS_PATH . «/» . $params [ «name» ] . «.component.php» );
} else {
echo «Component » . $params [ «name» ] . « not found»;
}
unset( $adodb , $errors , $security , $vars );
}
?>

Давайте разберемся, что делает данная функция. Во-первых, она создает обработчик для нового тега – {component}, во-вторых, достает (get_registered_object()) и делает доступными вызванному компоненту зарегистрированные ранее общие объекты.

Немножко теории. Чтобы вызвать данную функцию к жизни, необходимо в любом шаблоне написать тэг {component}. Поскольку функция не выполняет никаких продуктивных действий, и служит исключительно диспетчером компонентов, просто написать {component} недостаточно, поскольку эта команда неинформативна. Конечно, функция не даст сбоя, и запустит принятый по умолчанию компонент «site_view». Каким образом уточнить, какой именно компонент вам требуется и как передать ему дополнительные параметры? Все очень просто, мы несколько измени вызов компонента в шаблоне:{component name=«имя требуемого компонента» var1=«значение параметра» var2=«значение другого параметра»}

И так далее, как вы понимаете, name, var1, var2 – это дополнительные параметры для нашего компонента. Name, например, указывает имя компонента, который мы хотим вызвать, а остальные параметры – это дополнительные данные для вызываемого компонента, их количество может быть любым, ровно как и их имена. После того, как в шаблоне встретится указанный выше тег, произойдет вызов нашей функции, которая, в свою очередь, вызовет нужный вам компонент. Все дополнительные параметры будут доступны как в нашей функции так и в вызываемом компоненте, они будут содержаться в массиве $params, где ключ – это название параметра, а значение – соответственно – его значение.

Вступление

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

Часто, говоря о Smarty, незаслуженно обвиняют его в низкой производительности и «тормознутости», что ж – автор данного материала с указанными товарищами не согласен. Напротив, раз уж мы приняли решение использовать в своем приложении эту библиотеку, я предлагаю вам на полную катушку задействовать ее возможности, отдав на откуп шаблонизатору как вывод информации пользователю, так и управление этой информацией.

Компонентная модель

Одна из сильных сторон Smarty – это возможность создавать свои плагины и расширения. Воспользуемся этой его возможностью в полной мере и попробуем реализовать на ее основе компонентную модель сайта.

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

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

В результате сайт будет состоять из ядра — набора библиотек (классов), которые содержат в себе какие-то низкоуровневые действия, например работают с базой, – и компоненты, которые подключают эти библиотеки и, в нужном порядке, вызывают те или иные их методы.

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

Это основные преимущества данного подхода.

Общие классы

Безусловно, в каждом приложении есть набор классов, которые нужны всем, или большинству компонентов, например, класс для работы с базой. Как поступить в таком случае? И для этой проблемы в Smarty есть удачное решение. Впрочем, давайте по порядку.

Сначала инициализируем класс Smarty:<?php
/** Путь до Smarty */
define ( «SMARTY_DIR» , «/smarty/» );

/** Путь до Smarty шаблонов */
define ( «TEMPLATES» , «/templates/» );

/** Путь до Smarty компилированных шаблонов */
define ( «TEMPLATES_C» , «/templates_c/» );

require_once( SMARTY_DIR . «Smarty.class.php» );
$smarty = new Smarty;
$smarty -> compile_check = TRUE;
$smarty -> force_compile = TRUE;
$smarty -> template_dir = TEMPLATES;
$smarty -> compile_dir = TEMPLATES_C;
$smarty -> plugins_dir [] = LIBS_PATH;
$smarty -> caching = FALSE;
?>

Итак, Smarty готов к работе. Что необходимо сделать с общими классами, чтобы обеспечить доступ к ним внутри любого компонента?

Скажем, у нас есть несколько общих компонентов:
adodb – класс для работы с базой;
session – класс для работы с сессиями;
errors – класс для обработки ошибок;
variables – класс для хранения и обработки состояния массивов $_GET и $_POST.

Первым делом, нам необходимо создать объекты данных классов (параметры конструкторов зависят от вашей конкретной реализации). В целом, это делается стандартным образом:<?php
require_once( CLASSES_DIR . «/variables.class.php» );
$vars = new Variables ();

require_once( CLASSES_DIR . «/errors.class.php» );
$errors = new Errors ( $smarty );

require_once( CLASSES_DIR . «/security.class.php» );
$security = new Security ( $adodb );

// и так далее...
?>

Объекты созданы и теперь необходимо обеспечить доступ к ним в любом компоненте нашего приложения. Для этого необходимо зарегистрировать данные объекты в Smarty:<?php
$smarty -> register_object ( «adodb» , $adodb );

$smarty -> register_object ( «vars» , $vars );

$smarty -> register_object ( «errors» , $errors );

$smarty -> register_object ( «security» , $security );
?>

Для регистрации объектов мы используем метод Smartyregister_object(). После чего ваш объект станет доступным везде, где он может понадобиться. Как «достать» нужный вам зарегистрированный объект мы рассмотрим в следующей части.

Функция «Компонент»

К текущему моменту Smarty ничего не знает о каких-либо компонентах, и нам нам надо научить его работать с ними. Для этого мы добавляем к синтаксису шаблонов новый тег – {component}. Чтобы Smarty научился обрабатывать этот тег – пишем простую функцию:<?php
// Smarty function Component
//
// @author Feskov Kuzma

function smarty_function_component ( $params , & $smarty ) {
$adodb = & $smarty -> get_registered_object ( «adodb» );
$vars = & $smarty -> get_registered_object ( «vars» );
$errors = & $smarty -> get_registered_object ( «errors» );
$security = & $smarty -> get_registered_object ( «security» );

if (empty( $params [ «name» ])) {
$params [ «name» ] = «site_view»;
}
if ( is_file ( ADMIN_LIBS_PATH . «/» . $params [ «name» ] . «.component.php» )) {
require( ADMIN_LIBS_PATH . «/» . $params [ «name» ] . «.component.php» );
} else {
echo «Component » . $params [ «name» ] . « not found»;
}
unset( $adodb , $errors , $security , $vars );
}
?>

Давайте разберемся, что делает данная функция. Во-первых, она создает обработчик для нового тега – {component}, во-вторых, достает (get_registered_object()) и делает доступными вызванному компоненту зарегистрированные ранее общие объекты.

Немножко теории. Чтобы вызвать данную функцию к жизни, необходимо в любом шаблоне написать тэг {component}. Поскольку функция не выполняет никаких продуктивных действий, и служит исключительно диспетчером компонентов, просто написать {component} недостаточно, поскольку эта команда неинформативна. Конечно, функция не даст сбоя, и запустит принятый по умолчанию компонент «site_view». Каким образом уточнить, какой именно компонент вам требуется и как передать ему дополнительные параметры? Все очень просто, мы несколько измени вызов компонента в шаблоне:{component name=«имя требуемого компонента» var1=«значение параметра» var2=«значение другого параметра»}

И так далее, как вы понимаете, name, var1, var2 – это дополнительные параметры для нашего компонента. Name, например, указывает имя компонента, который мы хотим вызвать, а остальные параметры – это дополнительные данные для вызываемого компонента, их количество может быть любым, ровно как и их имена. После того, как в шаблоне встретится указанный выше тег, произойдет вызов нашей функции, которая, в свою очередь, вызовет нужный вам компонент. Все дополнительные параметры будут доступны как в нашей функции так и в вызываемом компоненте, они будут содержаться в массиве $params, где ключ – это название параметра, а значение – соответственно – его значение.

 

Интересное

10 советов по обеспечению...
Используйте Windows Server 2003 Версия Windows Server 2003 с поддержкой службы каталогов «Активная директория» (Active Directory, далее AD) гораздо безопаснее версии Windows 2000. Это не значит,...
Подробнее...
Установка Windows Server...
Семейство продуктов Windows Server 2003 берет все самое лучшее от технологии ОС Windows 2000 Server, упрощая при этом развертывание, управление и использование.В результате пользователь получает...
Подробнее...
Мужской стиль
Ни для кого не секрет, что одной из главных черт всех успешных деловых людей является умение хорошо выглядеть. На любых переговорах и встречах, деловой человек будет выглядеть впечатлительно....
Подробнее...
Ну сколько уж можно...
Можно ли операционную систему не переустанавливать по несколько раз в месяц?Мое однозначное мнение: операционную систему можно не переустанавливать по несольку раз в месяц, и это я собираюсь...
Подробнее...
Система автоматизации
Главными критериями успеха любого заведения, в частности ресторана, бара или кафе, являются: хорошая кухня, продуманный стиль, отличный сервис, и, обязательно, оперативная работа персонала с...
Подробнее...
Как появляется файловый...
Почему на жестком диске появляется множество ненужных данных? Причин существует множество, но в своем большинстве ненужные файлы являются результатом некорректной, не правильной работы разных...
Подробнее...
Интернет - трагедия или...
Доброго времени суток, уважаемый читатель. Я бы хотел поведать тебе, да и всем людям, мою точку зрения на влияние Интернета на людей, да и вообще, об Интернете в целом.Естественно, такую тему...
Подробнее...
Рекламное ПО и трояны...
Трояны составили 26.65% от общего числа заражений, обнаруженных в июле ActiveScan – бесплатным онлайновым сканером от Panda Security. Принимая во внимание процент инфекций, вызванных рекламными...
Подробнее...
Создание Web-броузера на...
Читая и перечитывая вопросы и ответы я все время натыкался на вопросы о компоненте T WebBrowser . Сначала я думал, что все просто, но когда самому понадобилось написать приложение с использованием...
Подробнее...
Прячем трафик: техника...
До сих пор рассматриваемые нами способы маскировки трафика сводились к сокрытию сетевых соединений, но на физическом уровне весь левый трафик элементарно обнаруживался сниферами и прочими...
Подробнее...