Translate

PHP Микрофреймворк HLEB

Скачать Скачать с GitHub
Предназначение Установить Настройка Структура проекта Маршрутизация Типы маршрутов Группы маршрутов Защита маршрутов Конструктор страниц Контроллеры Модели Получение данных Базы данных Дополнительно

Дополнительно

Установка и обновление: использование Composer

Установка и настройка: вариативное включение debug-режима

Настройка: Изменить папку public проекта на другую

Настройка: Изменить название директории vendor

Маршрутизация: установка формата для адреса

Маршрутизация: использование переменных в файлах роутов

Маршрутизация: работа с поддоменами

Модули: возможность модульной разработки

Памятка: защита проекта на фреймворке HLEB

Использование отладочной панели Debug Panel

Маршрутизация: регулярное выражение для динамических значений

Объект Request: данные динамического маршрута

Объект Request: обработка внешних данных

Шаблоны: использование includeTemplate

Шаблоны: кэширование при помощи includeCachedTemplate

Консоль: использование собственных консольных команд

Консоль: пример запуска команд в определённое время

Admin Panel: простая административная панель

Radjax: быстрый вспомогательный роутер

Шаблонизатор Twig: подключение

Шаблонизатор Twig: настройка

Установка и обновление: использование Composer

Установить актуальную версию проекта при помощи консольной команды (требует установленный менеджер пакетов Composer):
$ composer create-project phphleb/hleb
Обновить только ядро фреймворка (выполнить из папки с установленным проектом):
$ composer require phphleb/framework
Еси нужно обновить зависимости:
$ composer update

Установка и настройка: вариативное включение debug-режима

Несмотря на то, что для тестовой версии проекта и итоговой устанавливаются разные настройки в конфигурационном файле start.hleb.php, иногда бывает необходимо опционально включить debug-режим или другие настройки в публичной версии. Это можно реализовать двумя способами - переключить опционально на тестовый конфигурационный файл в /public/index.php или установить условие в файле start.hleb.php, например по определенномуip-адресу. Естественно, с этого адреса доступ может быть только у необходимого круга лиц.
// start.hleb.php define( 'HLEB_PROJECT_DEBUG', $_SERVER['REMOTE_ADDR'] == '127.0.0.1' );

Настройка: Изменить папку public проекта на другую

Чтобы установить вместо папки "public" другую, например, "public_html" - необходимо в корневом файле "console" изменить строчку:
// `console` file define( 'HLEB_PUBLIC_DIR', 'public_html' );
В остальном, если адрес ресурса уже направлен в "public_html", никаких изменений делать не нужно.

Настройка: Изменить название директории vendor

Для изменения названия папки "vendor" с библиотеками проекта, например, на "lib", в корневом файле "console" изменить в строчке:
// `console` file require(__DIR__ . "/lib/phphleb/framework/console.php");
Также в файле index.php изменить папку в пути для загрузчика на "lib":
// public/index.php include __DIR__ . '/../lib/phphleb/framework/bootstrap.php';

Маршрутизация: установка формата для адреса

Переданные с контроллером значения можно использовать для различных целей, например, для назначения локали и/или формата данных.
Route::get('/get_data/')->controller('AjaxTestController@data', ['json', 'en']);
// Файл /app/Controllers/AjaxTestController.php ... function data($format, $locale) { ... } ...
Реализация подобного назначения локали для группы маршрутов:
Route::before('SetLocaleBefore@index', ['ru'] ); Route::getGroup(); Route::get( ... ); Route::get( ... ); Route::endGroup();

Маршрутизация: использование переменных в файлах роутов

Так как карта маршрутизации содержит обычный код PHP, то допустимо использовать все его возможности с единственным ограничением: без использования внешних данных. Например, задание переменных:
$page = "test"; Route::get("/$page/first/", ... ); Route::get("/$page/second/", ... );
В данном примере на практике уместнее было бы использовать префикс группы. Однако, вынос значений в переменные может привести к созданию универсального шаблона маршрутов для использования в дальнейшем.

Маршрутизация: работа с поддоменами

Задать правила для поддоменов, а также, при надобности, для домена любого уровня, помогут два метода маршрутизации: domain() и domainTemplate().
Route::domain("dev")->getGroup(); Route::get("/", ... ); // dev.site.com или *.dev.site.com Route::endGroup(); Route::get("/", ... ); // все запросы (site.com или *.site.com)
Второй параметр в этих методах указывает на соответствие уровню домена, начиная от домена верхнего уровня (1), домена (2) и поддоменов (3 по умолчанию и далее), а первый аргумент может быть перечнем допустимых значений. Например:
Route::domain("sub4", 4)->domain("sub3")->get("/", ... ); // sub4.sub3.site.com или *.sub4.sub3.site.com Route::domain(["var1", "var2", null])->get("/", ... ); // var1.site.com, var2.site.com или site.com, а также *.var1.site.com или *.var2.site.com
Route::domain(null)->get("/", ... ); // без поддоменов, только site.com Route::domain("sub4", 4)->domain("*")->get("/", ... ); // sub4.*.site.com или *.sub4.*.site.com // метод domain("*") добавлен для наглядности маршрута, его можно не указывать
Так как в этих примерах адрес роута одинаковый ("/"), то следует обратить внимание на очередность роутов, будет выбран первый совпавший по URL, поэтому рекомендуется сначала располагать частные случаи, а затем общие.

Привязка маршрутов осуществляется без формального разделения на домен и поддомены, только по уровням иерархии доменного имени, начиная от домена верхнего уровня. В комментариях к этим примерам "site.com" аналогичен любым вариантам домена второго и первого уровня.

Метод domainTemplate() отличается только тем, что в первом аргументе передаются значения для проверки на совпадение в регулярном выражении.

Для кириллических поддоменов возможно придётся задавать условия только после конвертации названия поддоменов в Punycode.

Модули: возможности модульной разработки

Модульная разработка не нарушает базовый принцип MVC фреймворка. Для работы с его компонентами, в рамках изолированного модуля, не всегда удобно переключаться по папкам разных частей проекта. Поэтому предусмотрен вариант, когда все файлы разрабатываемого модуля расположены рядом. Отличие состоит в том, чтобы вместо метода controller() в маршрутизаторе использовать метод module().

Дополнительно необходимо создать папку "/modules" в корневой папке проекта. В ней будут располагаться модули с возможностью различного уровня вложенности.

/modules
    /example
        /DefaultModuleController.php
        /content.php
        /templates
            /origin.php

Все составляющие элементы используют внутренние ссылки на папку "modules".
Route::get('/test/module/example/')->module('example', 'DefaultModuleController');
Если вторым параметром не передано название класса контроллера, будет использовано "Controller".
Функция view() в данном случае также указывает на папку с текущим модулем "/modules/example".
Пространство имён зависит от пути до файла контроллера, как в приведённом примере:
// Файл /modules/example/DefaultModuleController.php namespace Modules\Example; class DefaultModuleController extends \MainController { function index() { return view('content'); } }
Функции шаблонов при использовании модуля тоже направляют в папку "modules".
// Файл /modules/example/content.php includeTemplate('/example/templates/origin');

Памятка: защита проекта на фреймворке HLEB

1 Отправка форм и ajax-запросов
1.1 Добавить в форму и/или запрос CSRF-защиту, предусмотренную фреймворком. Об этом здесь. Проверить, запросив с неправильным токеном и валидным.
1.2 Отправлять данные POST-методом.

2 DEBUG-режим
2.1 Использовать DEBUG-режим только при разработке.
2.2 Проект с запущенным DEBUG-режимом НЕ должен быть в свободном доступе из сети Интернет. Даже если на сайте все страницы без контента, специфический вывод панели отладки может спровоцировать нежелательный интерес со стороны сканирующих ботов.

3 Уникальный идентификатор проекта и кеш
3.1 При копировании проекта для иных целей, путем прямого переноса из папки, рекомендуется в перенесённой(!) конечной копии очистить весь кеш в папке "storage/cache".

4 Очистка входящих данных
4.1 Ограничивайте внешние данные по принципу "что не разрешено, то запрещено".
4.2 Используйте специальные методы маршрутов с регулярным выражением(where([...])), чтобы лишние символоы отбрасывались уже на этом уровне. В константе HLEB_PROJECT_VALIDITY_URL также можно ограничить допустимые символы в маршрутах для всего проекта.
4.3 Старайтесь не использовать GET-параметры для получения пользовательских данных, для этого должно хватить возможностей маршрутизации. Используйте методы объекта Request для получения очищенных параметров всех типов.
4.4 Основное внимание нужно обратить на то, чтобы пользовательские данные не попадали напрямую в базу данных (защита от SQL-инъекций), например, используя ORM. И также код JavaScript, а лучше любой код в тегах, был удалён при самом поступлении данных.
4.5 Указание кодировки каждой веб-страницы должно быть обязательным (в основном это кодировка UTF-8). Так данные будут интерпретированы в ожидаемом виде.
4.6 Использовать Content Security Policy (CSP). Это заголовок, который позволяет в явном виде объявить разрешённый список источников, с которых можно подгружать различные данные, например, JS, CSS, JPG и тд.
4.7 Запретите вставку страниц проекта в сторонние фреймы, если это не задумано заранее, минимальная защита представлена заголовком X-Frame-Options в файле start.hleb.php

5 Проверка антивирусными программами
5.1 Время от времени проверяйте файлы проекта специальными антивирусными программами.

6 Информирование об угрозах
6.1 Создайте скрипт, который регулярно проверяет проект и отправляет на email информацию о подозрительном изменении в файлах или иных незапланированных действиях. Желательно не использовать готовое решение.



Использование отладочной панели Debug Panel

В микрофреймворк HLEB добавлена отладочная панель, активная только в DEBUG-режиме. Она подключается при помощи строки:
// Файл /app/Optional/MainConnect.php ... [ "Phphleb\Debugpan\DPanel" => "vendor/phphleb/debugpan/DPanel.php" ] ...
После подключения можно настроить эту панель, добавив собственные данные для вывода, используя методы классов \Hleb\Main\MyDebug и \Hleb\Main\WorkDebug.

MyDebug

Создав класс FirstBefore или любым подобным способом:
// Файл /app/Middleware/Before/FirstBefore.php namespace App\Middleware\Before; use Hleb\Main\MyDebug; class FirstBefore extends \MainMiddleware { function index() { MyDebug::add("SERVER", $_SERVER ?? []); MyDebug::add("SESSION", $_SESSION ?? []); MyDebug::add("REQUEST", $_REQUEST ?? []); // Пример последовательного добавления if (isset($_COOKIE)) { foreach ($_COOKIE as $key => $value){ MyDebug::insert_to_array("COOKIE", "<b>$key</b>: " . $value); } } } }
Первым аргументом здесь указывается желаемое название вкладки, при этом для MyDebug::add() вторым параметром обязателен массив, а для MyDebug::insert_to_array() второй аргумент - любое значение, добавляемое в массив по имени. Также можно использовать метод MyDebug::insert_to_string(), в котором вторым аргументом добавляется строковое значение.

Теперь в отладочной панели появятся четыре дополнительные вкладки с параметрами, при условии, что этот класс подключён в карте маршрутов перед проверяемыми маршрутами.
Route::before('FirstBefore')->getGroup(); Route::get('/', 'Данные выведены в панель отладки.'); ... // Распространить правило на подключаемый файл include 'other_routes.php'; Route::endGroup();
Применение класса WorkDebug аналогично MyDebug, только служит для временного вывода данных при помощи var_dump, которые размещаются поверх страницы в отдельной панели. Отладочные данные этих классов доступны для добавления везде в проекте, кроме After-классов, которые выполняются после вывода основного контента.
\Hleb\Main\WorkDebug::add($data);
// Равносильно print_r2($data);
// С описанием \Hleb\Main\WorkDebug::add($data2, 'Описание data2');
Более простым и запоминающимся аналогом для вызова WorkDebug::add() является функция print_r2() c такими же аргументами.

Маршрутизация: регулярное выражение для динамических значений

Регулярное выражение в методе where() может принимать различные условия, в рамках правил составления регулярных выражений, например:
Route::get('/{page}/', 'Все вхождения по условию, кроме /map/.')->where(['page' => '(?!(map))[a-z0-9\-_]+']); Route::get('/map/', 'Отдельная обработка /map/.');
Данный пример не совсем отвечает интуитивно понятному способу составления карты маршрутов, в реальном проекте лучше определить эту закономерность при помощи очередности поиска подходящего маршрута:
Route::get('/map/', 'Отдельная обработка /map/.'); Route::get('/{page}/', 'Все вхождения по условию, кроме /map/.')->where(['page' => '[a-z0-9\-_]+']);

Объект Request: данные динамического маршрута

Объект Request содержит значения из URL по совпадению с динамическим маршрутом. Например, при запросе "site.com/first/" и наличии маршрута:
Route::before('TestMiddlewareBefore')->get('/{test}/')->controller('TestController')->after('TestMiddlewareAfter');
В каждом из контроллеров будет доступен объект Request c методом обращения get():
... use Hleb\Constructor\Handlers\Request; ... var_dump( Request::get()); // array(1) { ["test"]=> string(5) "first" } var_dump( Request::get('test')); // string(5) "first"

Объект Request: обработка данных запроса

Через методы объекта Request (Hleb\Constructor\Handlers\Request) также можно получить различные данные пользовательского запроса.

Request::getMethod() - получение метода запроса из $_SERVER['REQUEST_METHOD'], к примеру 'GET', 'POST', 'PUT'
Request::getUri() - URI, который был предоставлен для доступа к этой странице. Например, '/index.html'
Request::getReferer() - определяет адрес предыдущей страницы, при его существовании, с которого пользователь осуществил переход.
Request::getHost() - возвращает интернет-хост и номер порта запрашиваемого ресурса.
Request::getFullUrl() - возвращает полный url-адрес ресурса, без GET-параметров.
Request::getHttpHeader(<значение>) - обращается к значениям $_SERVER.
Request::getCookie(<значение>) - возвращает значение $_COOKIE.
Request::getSession(<значение>) - возвращает значение $_SESSION.
Request::getRemoteAddress() - возвращает IP-адрес, с которого пользователь просматривает текущую страницу.
Request::getGet(<значение>) - возвращает данные GET-запроса из $_GET по значению.
Request::getPost(<значение>) - возвращает данные POST-запроса из $_POST по значению.
Request::getRequest(<значение>) - возвращает данные POST-запроса или GET-запроса из $_REQUEST по значению.

Request::getHead()->addStyles(<url>) - добавляет ссылку на CSS-файл с подключаемыми стилями.
Request::getHead()->addScript(<url>) - добавляет ссылку на JS-файл с подключаемыми скриптами.
Request::getHead()->setTitle(<текст>) - вывод в <head><title>...</title></head>.
Request::getHead()->setDescription(<текст>) - установка META-тега описания страницы.
Request::getHead()->addMeta(<название>, <контент>) - задание произвольного META-тега.
<?php getRequestHead()->output(); ?> - помещенное в <head>...</head> страницы, отображает все предыдущие установленные данные getHead().

Request::getResources()->addBottomStyles(<url>) - добавляет ссылку на CSS-файл в нижней части страницы.
Request::getResources()->addBottomScript(<url>) - добавляет ссылку на JS-файл в нижней части страницы.
<?php print getRequestResources()->getBottomStyles(); ?> - получение данных стилей для вывода на странице (в нижней её части).
<?php print getRequestResources()->getBottomScripts(); ?> - получение данных JS-файлов для вывода на странице (в нижней её части).


Шаблоны: использование includeTemplate

Части кода в подключаемых файлах папки views могут повторятся. Чтобы вынести их в отдельный шаблон, независимый от окружающего контента, используется функция includeTemplate(), первым аргументом которой указывается название шаблона из папки resources/views, а вторым - массив переменных, которые будут доступны в шаблоне по ключам массива. Для отличия шаблонов от других файлов их рекомендуется разместить в отдельной папке templates.

Данные шаблоны могут обращаться только к ".php" файлам, поэтому они не используются при работе с шаблонизатором (Twig), который включает собственные способы управления контентом.
// Файл /resources/views/content.php includeTemplate('templates/name', ['variable1'=>'value1', 'variable2'=>'value2']);
// Файл /resources/views/templates/name.php echo $variable1; // data1 echo $variable2; // data2 // или echo $this->variable1; // data1 echo $this->variable2; // data2

Шаблоны: кэширование при помощи includeCachedTemplate и includeOwnCachedTemplate

В отдельных случаях, если содержимое шаблона требует существенных расчётов, но данные неизменны некоторое время, есть возможность задать кэширование. Чем больше производительности требуют эти вычисления, тем больший прирост в скорости обработки блока можно получить при последующих обращениях, так как в кэше он сохранен как обычный html-текст.
Кэширование будет привязано к заданному времени в методе setCacheTime(), который необходимо расположить в шаблоне для функции includeCachedTemplate(). Аргументы последней индентичны функции includeTemplate(), единственное отличие, что заданное в шаблоне время кэширования приведет к кэшированию содержимого. Все изменения содержимого шаблона будут недоступны до истечения указанного срока. Также следует учесть, если шаблон задан через аналогичную функцию includeOwnCachedTemplate() и в нём установлено время кэширования, то где бы он не был использован в проекте, кэшированное значение его будет для текущего пользователя одинаковым. Таким образом функция includeOwnCachedTemplate отличается от includeCachedTemplate привязкой к пользовательской сессии, что ведёт к значительному увеличению размера кэша, а также более низкой его эффективности, но зато позволяет включать в кэш пользовательские данные.
// Файл /resources/views/content.php includeCachedTemplate('templates/cached/name');
// Файл /resources/views/templates/cached/name.php $this->setCacheTime(60); // задание времени кеширования в секундах echo rand(); // рандомное число будет неизменно в течении минуты

Кэширование должно быть рациональным и обдуманно применено в каждом случае, иначе результат может слишком явно не соответствовать вычисляемым данным. Например, рекомендуется кэшировать блоки, содержащие информацию, которая рассчитывается из текущего названия месяца или ежедневно обновляемого курса валют. Но и в таком случае значение желательно устанавливать не более 10 минут (600 секунд).
Если это определение без особых затрат производительности, вроде прямого получения даты из PHP-функции date(), то эффективности от кэширования не будет.

Также, при использовании дополнительно передаваемых параметров во втором аргументе данных функций, возможно отсутствие пользы от кеширования, если эти параметры часто изменяются. Для каждого варианта из этих параметров будет создан собственный соответствующий кэш.
В случае возникновения каких-либо сомнений при использовании этой функции, лучше заменить её на функцию includeTemplate().
Для удаления всего кэша шаблонов - удалить содержимое папки /storage/cache/templates/ или специальной консольной командой.

Консоль: использование собственных консольных команд

Перечень встроенных консольных команд отображается командой php console --help, выполненной в корневой директории проекта.
$ php console --help
--version or -v (версия фреймворка)
--clear-cache or -cc (очистка кэша шаблонов и маршрутов)
--info or -i (вывод настроек)
--help or -h (помощь)
--routes or -r (вывод списка маршрутов)
--list or -l (вывод списка пользовательских команд)

Создать собственную консольную команду при помощи добавления соответствующего класса в app/Commands/:
// Файл /app/Commands/DefaultTask.php namespace App\Commands; class DefaultTask extends \Hleb\Scheme\App\Commands\MainTask { // php console default-task [arg] const DESCRIPTION = "Default task"; // Короткое, но информативное описание команды. protected function execute($arg = null) // Переменная $arg будет содержать необязательный дополнительный аргумент. { // Содержимое класса } }
Теперь можно вызвать эту команду по принципу соответствия DefaultTask > default-task.
$ php console default-task
Если, например, класс расположен в папке app/Commands/Folder/, то вызвать его можно таким образом:
$ php console folder/default-task
Стоит учесть, что при расположении класса в папке app/Commands/Folder/, его namespace должно быть App\Commands\Folder.

Добавление произвольного значения "test", которое будет передано в переменной $arg :
$ php console default-task test

Если необходимо передать два или более аргументов с командой, то их необходимо указать в методе execute, например так: execute($arg1, $arg2, $arg3).

Консоль: пример запуска команд в определённое время

Если выполнение команд происходит при помощи cron, с 1.2.3 версии фреймворка добавлена возможность собрать несколько команд в одной основной и запускать в зависимости от назначенного времени. B cron указывается только выполнение основной команды, каждую минуту. Таким образом, при переносе проекта, достаточно задать одну команду на выполнение. Например, в основной команде systematic-launch-task заданы две исполняемые команды.
// Файл /app/Commands/SystematicLaunchTask.php namespace App\Commands; use Hleb\Main\Commands\MainLaunchTask class SystematicLaunchTask extends \Hleb\Scheme\App\Commands\MainTask { // php console systematic-launch-task const DESCRIPTION = "Main launch all selected Tasks"; protected function execute() { // В начале каждого часа $this->everyHour("/usr/local/bin/php7.3 ~/hleb/console default-task test"); // Каждый день в 04:05 if ($this->givenHour(4) { $this->givenMinutes(5, [ "/usr/local/bin/php7.3 ~/hleb/console rotate-logs-task &" ]); } } }
Подробный перечень методов, задающих время выполнения, можно найти в классе MainLaunchTask, от которого унаследован основной класс. Методы, определяющие конкретные минуты, могут принимать список этих команд в виде массива, остальные могут служить условием запуска.

everyMinute(<commands>) - каждую минуту.
everyHour(<commands>) - каждое начало часа.
everyDay(<commands>) - каждый день в 00:00.
givenMinutes(<minute>, <commands>) - первым аргументом минуты часа (0-60) в массиве или числовое значение.
givenHour(<hour>) - часы (0-12) в массиве или числовое значение.
givenMonth(<month>) - месяцы (1-12) в массиве или числовое значение.
givenWeeklyDay(<day>) - значения дня недели (1-7) в массиве или числовое значение.
givenMonthlyDay(<day>) - значения дня месяца (1-31) в массиве или числовое значение.
givenYearDay(<day>) - значения дня года (1-365) в массиве или числовое значение.


Admin Panel: простая административная панель

В версии 1.1.5 фреймворка добавлен новый метод маршрутизации adminPanController(). Он необходим для использования библиотеки phphleb/adminpan, которая подключается отдельно.
$ composer require phphleb/adminpan
Метод adminPanController() аналогичен методу controller(), с той разницей, что отображаемый им контент будет встроен в оболочку административной панели.
Route::get('/admin/panel/main/')->adminPanController('AdminController@main', 'Page Name');
Следует использовать только прямые указания пути для маршрутов данного контроллера, чтобы в его меню правильно отображались ссылки на другие роуты adminPanController() и названия ссылок (в примере выше это "Page Name").
К странице в дальнейшем допустимо подключить какой-нибудь СSS- и/или JS-фреймворк в коде подключаемого контента.

Кроме того, можно воспользоваться встроенными инструментами формирования таблиц и списков.
// Файл /app/Controllers/AdminController.php namespace App\Controllers; use Phphleb\Adminpan\MainAdminPanel; class AdminController extends \MainController { function main() { $panel = new MainAdminPanel(); // Вывод HTML $content = $panel->getDataHTML("<b>HTML</b>");
// Вывод нумерованного списка $content .= $panel->getDataList(["Text 1", "Text 2", "Text 3"]);
// Вывод массива с данными в виде таблицы $data = UserModel::getData(); $content .= $panel->getDataTable($data);
return $content ; } }
Таким же образом методы класса MainAdminPanel доступны в view-файлах, возвращаемых из контроллера функцией view().


Radjax: быстрый вспомогательный роутер

Данный маршрутизатор не включен в основной пакет фреймворка, его можно установить через Composer:
$ composer require phphleb/radjax
После установки остается только назначить роуты в файле /routes/ajax.php или /routes/api.php проекта. Эти роуты просты и отличаются от роутов фреймворка HLEB. В них присутствует один метод get(), через который и настраивается конфигурация. Следует отметить, что, кроме этих отличий, есть ещё несколько:

1) Если тип маршрута (GET, POST и тд.) из конфигурации не подходит, нo адрес маршрута совпал, Radjax-роутер не пропустит поиск далее, как это реализовано во фреймворке, а выдаст ошибку 405 (метод не поддерживается) c перечислением корректных для этого маршрута типов в заголовке.

2) Константы для настроек фреймворка (/start.hleb.php) также влияют на код Radjax-роутера, хотя он функционирует независимо и запускается отдельно от фреймворка, из-за чего его производительность выше. В большинстве, от роутера такого типа, требуется только получить или сохранить данные по запросу и отобразить ответ в виде json или xml.

3) Radjax может проверять токен, генерируемый фреймворком для защиты от CSRF-атак, если включен параметр protected данного роутера, но не устанавливает токен самостоятельно. Поэтому, используемый для ajax-запросов роутер проверяет существующий токен, как минимум уже установленный в сессию на странице, с которой был выполнен запрос. При использовании роутера как API, параметр protected следует отключить, чтобы сторонние ресурсы могли запрашивать данные. Дубликат токена для проверки добавляется со страницы GET- или POST-параметром "_token".

4) Файл /routes/ajax.php или /routes/api.php может включать только специальные роуты Radjax, эти файлы не нужно инклюдировать в файл /routes/main.php, как в случае с другими файлами роутинга фреймворка.

5) Класс контроллера указывается полностью, вместе с его namespace, например, "App\Controllers\Api\MainController", а при не обнаружении метода класса, указанного после знака "@", поиск продолжается по указанному методу с добавлением приставки "Http{Type}", где Type это текущий тип HTTP запроса. Например, для "App\Controllers\Api\MainController@test" и указанием поддерживаемого типа ["post"], в соответствующем классе сначала будет произведен поиск метода test(), а если он не будет найден, то testHttpPost().

6) По умолчанию реализовано чтение файлов сессий, но не их сохранение, это улучшает обработку конкурентных ajax-запросов. Однако, возможность сохранения изменений в сессию можно включить в конфигурации роута, указав "save_session" => true.

Radjax\Route::get('/customers/{number}/orders?/', ["get","post"], "App\Controllers\CustomersController@orders", ["protected" => true, "where"=>["number" => "[0-9]+"], "save_session" => false]);
Как видно из примера, первым параметром идёт адрес роута, в нём значение number динамическое и доступно из Request::get("number"), а знак "?" после orders обозначает, что эта часть адреса не обязательна для совпадения. Вторым параметром указан массив с типами HTTP-запроса, на третьей позиции класс контроллера и метод класса, четвертым аргументом включён массив необязательных именованных параметров.

Шаблонизатор Twig: установка

При желании можно подключить к фреймворку шаблонизатор Twig. Он будет работать через автозагрузку классов, генерируемую Composer.
$ composer require "twig/twig:^3.0"

Шаблонизатор Twig: настройка

После установки, если указать расширение файла в функции view() маршрута или контроллера, файл будет передан в обработку Twig. Иначе он будет выполнен как обычный PHP-файл.
Route::get('/handler/twig/', view('template/main.twig', ['p1'=>'data1', 'p2'=>'data2']));
При добавлении в файл hleb.start.php следующих констант, значения их будут управлять действиями шаблонизатора:

HL_TWIG_CACHED_ON (bool), включение кеширования для шаблонов. По умолчанию отключено.
HL_TWIG_AUTO_RELOAD (bool), автоматическая перекомпиляция шаблонов. Изначально ориентировано на режим отладки.
HL_TWIG_STRICT_VARIABLES (bool), включение строгого режима, при котором будут выдаваться ошибки, если существующая переменная не передана в шаблон. По умолчанию отключено.




Предназначение Установить Настройка Структура проекта Маршрутизация Типы маршрутов Группы маршрутов Защита маршрутов Конструктор страниц Контроллеры Модели Получение данных Базы данных Дополнительно



Этот сайт-инструкция к фреймворку HLEB сделан с использованием фреймворка HLEB.

HLEB - PHP Микрофреймворк Свободная лицензия. Без гарантий. © fomiash 2019-2020