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

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

Стандартный контроллер микрофреймворка HLEB - это обычный динамический класс PHP, методы которого используются для обработки входящих данных и возвращают результат в виде функции view(), html-строки, функции render() или редиректа на другой адрес. Поэтому к этому разделу инструкции стоит приступать после ознакомления с маршрутизацией и конструктором страниц, реализованных в данном микрофреймворке.

Стандартным контроллером, который взаимодействует с методом get(), подменяя его второй аргумент, является метод controller(). Вследствие чего он способен возвращать перечисленные функции и прочие указанные результаты по итогам обработки входных значений.

Метод controller()

Этот метод используется только в паре с методом get(), должен идти сразу за ним и применятся к конкретному методу get() один раз. Эти ограничения выходят из самого их взаимодействия, как уже упоминалось, метод controller() заменяет второй аргумент в методе get().

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

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

Если в контроллере маршрута указано только название контроллера, вызов будет направлен методу index() класса контроллера, однако можно указать любой публичный метод контроллера. Например, если у контроллера "TestController" существовал бы метод checkCookies(): Данные для условия, которые доступны в классе контроллера, описаны в разделе «Получение данных», это объект Request c переменными из динамического маршрута, а также переданные с контроллером значения. В том числе, могут проверятся и вычисляться любые другие доступные данные, например, исходя из $_COOKIES, $_REQUEST, $_SESSION.

Переданные с контроллером значения предназначены для исключительного использования, представляют из себя массив с данными, передаваемый вторым необязательным аргументом в метод controller(). Сделано это для полноценной замены второго параметра метода get() маршрутизатора. Строковые ключи этого массива преобразуются в аргументы метода класса контроллера. Например, если бы вызов был: В классе "TestController" у метода index() в таком случае должны быть два принимающих аргумента: Контроллеры стандартного типа чаще используются для предварительного получения данных, обращаясь к Модели(получение информации из базы данных в необходимом виде):

Методы before() и after()

Данные методы также относятся к контроллерам, но обращаются к классам-посредникам, располагаясь как до и после метода get(), так и между собой, вследствие этого применение их не ограничено в количестве для одного маршрута. Отличаются от метода controller() тем, что не возвращают результат, но производят необходимые проверки и могут включать в себя редирект на другой URL, если это метод before(), всегда применяемый до метода get(). Метод after() может быть использован для любых действий после определения вывода данных пользователю, например вывод информации в лог на основе этих данных или отправка её по E-mail. Теоретически, последнее может быть более рационально реализовано совместно с PHP-функцией ob_get_flush().

Классы этих посредников имеют место в папках "/app/Middleware/Before" и "/app/Middleware/After" соответственно. Преимущество данных методов перед controller() в возможном применении не только к маршруту, но и группе маршрутов.

Важно! Метод before() располагается до группы или маршрута, к которому применяется, а after() - таким же образом, после.

Аналогично методу controller() посредники имеют второй необязательный аргумент, принимающий массив значений, и дополнительный разделитель "@", определяющий, в какой метод класса отправить вызов.

Пример определения авторизации для группы маршрутов: Если метод контроллера возвращает false то произойдет немедленное завершение выполнения (exit).
При возврате массива из метода контроллера он будет преобразован и отображен как json c соответствующими заголовками и с дальнейшим завершением выполнения программы.

Выбор контроллера и метода в зависимости от запроса

Многие фреймворки используют сокращение в роутинге, когда выбор контроллера и его метода зависит от входящего запроса в url. Поэтому такой способ может показаться привычным.
В фреймворке HLEB (с версии 1.5.54) также можно провести такое соответствие, используя теги в названии контроллера и его метода, доступно только для controller() и module().

Такой способ, с одной стороны, упрощает написание адресов для маршрутизации, с другой - требует дополнительной внимательности к вызываемым методам и структуре классов контроллеров, так как в замещение может попасть любой адрес и вызвать непредвиденный метод произвольного класса.
При совпадении вариативного маршрута и отсутствии нужного класса/метода отобразится стандартная ошибка 404, если вызов необъявленных методов не был перехвачен в классе.
В случае совпадения произойдет подстановка '/en/pages/create/' в 'PagesController@getCreate' из примера, а если в url разрешены дефисы, то '/main-page/' в запросе контроллера будет обращена к 'MainPageController', аналогично для методов.

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