Вакансии

Компоненты 2.0: настройка поддержки ЧПУ

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

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

Понятие обработки адресов

Обработка адресов (UrlRewrite) применяется для того, чтобы скрипт мог отвечать не только по своему физическому, но и по любому другому указанному адресу. Например, можно задать такие настройки обработки адресов, что скрипт, лежащий в файле /fld/c.php и отвечающий по адресу:
     /fld/c.php?id=15
будет отвечать также по адресу:
     /catalog/15.php

Адрес, по которому будет отвечать скрипт, не должен физически существовать на сервере. Если такой адрес физически существует, то будет вызван скрипт по этому адресу. Система обработки адресов запущена в этом случае не будет.

Управление правилами преобразования адресов производится на странице: /bitrix/admin/urlrewrite_list.php.
Механизм переопределения адресов создан в основном для компонентов 2.0, поддерживающих режим ЧПУ. В то же время, данный обработчик можно использовать для переопределения любых URL, а не только связанных с компонентами.

При добавлении на страницу компонента с поддержкой ЧПУ (если файл сохраняется с помощью API), автоматически создается правило переопределения адреса. Если страница создается не с помощью API, а, например, записывается через FTP, то необходимо выполнить пересоздание правил (кнопка на панели инструментов на странице управления правилами).

Подключение механизма обработки адресов:

1. Если у вас на веб-сервере настроена обработка ошибки 404, например, для Apache установлена опция ErrorDocument или аналогичная инструкция прописана в файле .htaccess:
     ErrorDocument 404 /404.php,
то вы должны изменить файл /404.php, вставив в самое начало файла команду:
    include_once( $_SERVER['DOCUMENT_ROOT']. '/bitrix/modules/main/include/urlrewrite.php' );

2. Если вы для Apache используете модуль mod_rewrite, то в его настройках вы можете указать (например, в файле .htaccess):
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-l
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !/bitrix/urlrewrite.php$
RewriteRule ^(.*)$ /bitrix/urlrewrite.php [L]
</IfModule>

После этих настроек будет работать штатный механизм поддержки ЧПУ для новых компонент.

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

Инструменты для оценки и отладки производительности компонент и всего сайта в целом

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

show_page_exec_time=Y - выводит общее время исполнения страницы;

show_include_exec_time=Y - выводит время исполнения каждой из компонент, время формирования меню.

В корреляции с этими параметрами работает параметр show_sql_stat=Y, который выводит число SQL запросов, общее время исполнения SQL запросов и позволяет проанализировать сами запросы, как на всю страницу, так и на отдельно взятый компонент или меню.

Пример:

На этом рисунке представлена статистика SQL запросов для компоненты новостей на главной странице. Выводится она 2 запросами. Общее время работы компоненты составляет 0.0463 сек. Время SQL запросов 0.0274 сек. или 59.18% от времени работы компоненты (% помогает выявлять ресурсоемкий PHP код или тяжелые запросы). Возле каждого запроса указывается, сколько раз аналогичные запросы повторялись с вариацией параметров, сколько времени выполнялся запрос. В статистике перечисляется, откуда вызван запрос и с какими параметрами.

Рассмотрим другой пример: запросы на странице блогов.

Количество запросов равно четырем. Но они потребляют меньше 4% от времени компоненты, которое составляет 0.0228 сек. Важно, что количество запросов не играет решающей роли, важнее время выполнения запросов.

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

Наверх

Пользовательские движки шаблонизации

Добавление нового движка шаблонизации на сайт

Для добавления нового движка шаблонизации на сайт в файл /bitrix/php_interface/init.php необходимо добавить следующее:

1. Глобальную переменную $arCustomTemplateEngines, которая содержит ассоциативный массив, каждый элемент которого имеет вид:
   "код_шаблонизатора" => array(
      "templateExt" => array("расширение1"[, "расширение2"...]),
      "function" => "имя_функции_подключения_движка"
   )
где:
"код_шаблонизатора" - произвольное уникальное в рамках сайта слово;
"расширениеN" - расширение файла, который должен обрабатываться этим движком шаблонизации;
"имя_функции_подключения_движка" - имя функции, которая будет вызываться, если шаблон компонента имеет указанное расширение.

2. Функцию подключения движков:
     function имя_функции_подключения_движка($templateFile, $arResult, $arParams, $arLangMessages, $templateFolder, $parentTemplateFolder, $template),
где:
     $templateFile – путь к файлу шаблона относительно корня сайта,
     $arResult – массив результатов работы компонента,
     $arParams – массив входных параметров компонента,
     $arLangMessages – массив языковых сообщений (переводов) шаблона,
     $templateFolder – путь к папке шаблона относительно корня сайта (если шаблон лежит не в
папке, то эта переменная пуста),
     $parentTemplateFolder - путь относительно корня сайта к папке шаблона комплексного
компонента, в составе которого подключается данный компонент (если компонент
подключается самостоятельно, то эта переменная пуста),
     $template – объект шаблона.

Рассмотрим подключение движков на конкретных примерах.

Пример подключения движка Smarty:

В массиве $arCustomTemplateEngines регистрируется движок Smarty:

global $arCustomTemplateEngines;
$arCustomTemplateEngines = array(
   "smarty" => array(
      "templateExt" => array("tpl"),
      "function" => "SmartyEngine"
   ),
);

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

function SmartyEngine($templateFile, $arResult, $arParams, $arLangMessages, $templateFolder, $parentTemplateFolder, $template)
{
   if (!defined("SMARTY_DIR"))
      define("SMARTY_DIR", "<абсолютныйпутькдвижку Smarty>/libs/");

   require_once( '<абсолютныйпутькдвижку Smarty>/libs/Smarty.class.php' );

   $smarty = new Smarty;

   $smarty->compile_dir = "<абсолютныйпутькдвижку Smarty>/templates_c/";
   $smarty->config_dir = "<абсолютныйпутькдвижку Smarty>/configs/";
   $smarty->template_dir = "<абсолютныйпутькдвижку Smarty>/templates/";
   $smarty->cache_dir = "<абсолютныйпутькдвижку Smarty>/cache/";

   $smarty->compile_check = true;
   $smarty->debugging = false;

   $smarty->assign("arResult", $arResult);
   $smarty->assign("arParams", $arParams);
   $smarty->assign("MESS", $arLangMessages);
   $smarty->assign("templateFolder", $templateFolder);
   $smarty->assign("parentTemplateFolder", $parentTemplateFolder);

   $smarty->display( $_SERVER["DOCUMENT_ROOT"].$templateFile );
}

В строке "<абсолютныйпутькдвижку Smarty>" указывается абсолютный путь к движку Smarty.

Пример подключения движка XML/XSLT:

Сначала регистрируем движок:

global $arCustomTemplateEngines;
$arCustomTemplateEngines = array(
   "xslt" => array(
      "templateExt" => array("xsl"),
      "function" => "XSLTEngine"
   ),
);

Функция инициализации параметров движка:

function CreateXMLFromArray($xDoc, $xNode, $ar)
{
   foreach($ar as $key=>$val)
   {
      if(!is_string($key) || strlen($key)<=0)
         $key = "value";

      $xElement = $xDoc->createElement($key);
      if(is_array($val))
      {
         CreateXMLFromArray($xDoc, $xElement, $val);
      }
      else
      {
         $xElement->appendChild($xDoc->createTextNode(iconv( SITE_CHARSET, "utf-8", $val)));
      }
      $xNode->appendChild($xElement);
   }
   return $xNode;
}

Функция подключения движка:

function XSLTEngine($templateFile, $arResult, $arParams, $arLangMessages, $templateFolder, $parentTemplateFolder, $template)
{
   $arResult["PARAMS"] = array(
      "templateFolder" => $templateFolder,
      "parentTemplateFolder" => $parentTemplateFolder,
      "arParams" => $arParams,
      "arLangMessages" => $arLangMessages
   );

   $xDoc = new DOMDocument("1.0", SITE_CHARSET);
   $xRoot = $xDoc->createElement('result');
   CreateXMLFromArray($xDoc, $xRoot, $arResult);
   $xDoc->appendChild($xRoot);

   $xXsl = new DOMDocument();
   $xXsl->load( $_SERVER["DOCUMENT_ROOT"].$templateFile );

   $xProc = new XSLTProcessor;
   $xProc->importStyleSheet($xXsl);

   echo $xProc->transformToXML($xDoc);
}

Наверх

Комплексные компоненты

Описание новой технологии в "Битрикс: Управление сайтом 6.0" Определение

Обычные (простые, одностраничные) компоненты создают какую-либо область на одной конкретной странице. Например, компонент показа новости по ее коду создает на одной конкретной странице (той, где он размещен) область, в которой показывает заголовок, текст и прочие параметры новости.

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

MVC

Комплексные компоненты построены на паттерне проектирования MVC (Model View Controller), в котором модель данных приложения, пользовательский интерфейс и управляющая логика разделены на три отдельных части, так, что модификация одной из частей оказывает минимальное воздействие на другие части.

Model (модель) в данном случае - это ядро системы. Model представляет собой данные и бизнес-логику, отвечает на запросы View. View (представление) - это простые компоненты (на самом деле все чуть сложнее, но для начала можно понимать именно так). View представляет вывод данных пользователю, запрашивает данные у Model, посылает действия пользователя в Controller (как правило через HTTP запрос). Controller (контроллер) - это комплексный компонент. Controller на основании действий пользователя и ответа Model выбирает соответствующий View.

Алгоритм работы паттерна MVC примерно таков: на основании действий пользователя Controller (контроллер) определяет, какое View (представление) должно быть показано пользователю, и отдает управление этому View (представлению); View (представление) запрашивает необходимые ему данные у Model (модели), получает эти данные и выводит их соответствующим образом пользователю; пользователь с помощью каких-либо элементов управления, которые ему предоставил View (представление), посылает новый запрос в Controller (контроллер).

Алгоритм работы паттерна MVC в применении к комплексным компонентам таков: на основании действий пользователя (как правило HTTP запрос) комплексный компонент (controller) определяет, какая страница (view) должна быть показана пользователю, и подключает свой шаблон компонента для этой страницы; шаблон страницы (view) подключает обычные компоненты, настраивая необходимым образом их свойства; обычные компоненты выполняют свою работу: запрашивают данные у ядра (model), форматируют их и выводят посетителю, а так же предоставляют пользователю различные элементы управления (ссылки, формы, кнопки и т.п.); пользователь с помощью каких-либо элементов управления, посылает новый запрос (как правило HTTP запрос) комплексному компоненту (controller).

Пример

Расмотрим упрощенный пример работы комплексного компонента новостей. Пусть у нас есть обычные компоненты список новостей и детальной новости (последний принимает во входных параметрах код новости, которую нужно показать).

Раздел новостей можно организовать, например, разместив на странице index.php компонент списка новостей, а на странице news.php - компонент детальной новости. При этом у компонента списка новостей нужно настроить входные параметры так, чтобы он мог формировать ссылки на страницу детальной новости (с кодом новости), а у компонента детальной новости нужно настроить входные параметры так, чтобы он мог формировать ссылку на страницу списка новостей. Для того, чтобы задать ссылку на страницу детальной новости, нужно задать путь к этой странице, а так же название параметра, в котором будет передаваться код новости для показа. То же название параметра нужно задать и во входных параметрах компонента детальной новости, чтобы он знал, где брать код новости для показа. Даже в данном максимально упрощенном случае настройки не так просты. А если это набор из десятков компонентов форума?

Более удобной альтернативой для сборщика сайта будет использование комплексного компонента новостей. Этот компонент, например, можно просто установить на страницу index.php и все. Согласованием ссылок и параметров будет заниматься сам комплексный компонент. От сборщика сайта никаких дополнительных действий не потребуется. Для создания комплексного компонента новостей нам необходимо создать новый компонент, в коде которого проверить, пришел ли в параметрах код новости. Если код новости пришел, то нужно подключить страницу шаблона комплексного компонента, которая предназначена для показа детальной новости, а если не пришел - страницу для показа списка новостей. Страницы шаблона комплексного компонента будут содержать подключение соответствующих обычных компонентов с правильной настройкой их входных параметров. Обычные компоненты будут выполнять свою обычную работу. Им все равно, кто их вызвал и зачем. Для обычных компонентов важна только правильная настройка их входных параметров.

Таким образом реализуется паттерн MVC: на комплексный компонент новостей (controller) приходит HTTP запрос (действия пользователя); комплексный компонент новостей (controller) проверяет, установлен ли через HTTP запрос код новости и подключает из своего шаблона страницу списка новостей или страницу детальной новости (view); подключенная страница в свою очередь подключает соответствующий обычный компонент, устанавливая при этом его входные параметры соответствующим образом; обычный компонент выполняет свою работу: запрашивает данные у ядра (model), форматирует их и выводит посетителю, а так же предоставляет пользователю различные элементы управления (ссылки, формы, кнопки и т.п.); пользователь с помощью каких-либо элементов управления, посылает новый HTTP запрос на комплексный компонент новостей (controller); и далее по кругу.

Наверх