простой роутинг на php
PHP-роутинг (Routing) для новичков
Роутинг — это маршрутизация: входящий URL разбирается специальным образом и по его результату выполняется определенный код. С роутингом напрямую связано понятие ЧПУ (человекопонятные урлы), которое позволяет исключить в адресах сложные параметры. Например вместо http://сайт/admin/new-page пришлось бы использовать http://сайт/admin.php?action=new-page
Любой входящий URL на сервере разбирается по единому стандарту. Полностью приводить документацию не буду (см. как пример функцию parse_url), важно лишь понять, что в адресе передается параметр path (путь на сервере), которого на сервере реально может не быть. Например в адресе http://сайт/admin каталога admin реально может не существовать.
Чтобы исключить такой вариант, серверу указывается, что для всех несуществующих каталогов и файлов, подключать php-файл (обычно index.php ).
Тут главная строчка с RewriteRule — именно она определяет шаблон входящего адреса (в примере это регулярное выражение) и что с ним делать. В данном примере будет подключен index.php с параметрами после слэша.
Похожий вариант, только чуть короче, от WordPress:
Здесь принудительно добавляется query-параметр page.
Еще один распространенный вариант (пожалуй самый «типовой»):
Все эти RewriteRule-правила делают простую вещь: как бы «преобразуют» входящий адрес в набор query-параметров. Например адрес http://сайт/admin превратится в http://сайт/index.php?admin
Если это какой-то подкаталог, то он указываетс в RewriteBase и как путь к php-файлу. Например каталог на сервере route :
Если в index.php разместить
Существуют несколько принципиально разных подходов в организации роутинга. Наиболее популярный подход — это когда в адресе передаётся «действие», которое описывается через php-класс. Такой подход хорошо описан в CodeIgniter:
Это сильно утрированный пример, но он хорошо показывает соответствие адреса и php-класса.
Другой вариант похожий, но используется не классы, а функции.
То есть функция — это первый сегмент, а остальные выступают уже как парметры. Встречается более «продвинутый» вариант.
То есть имя функции строится по сегментам URL.
Третий, тоже распространенный вариант — адрес указывает на подключаемый файл.
Здесь все файлы хранятся в каталоге pages и подключаются только если реально существуют. Если файла нет, то подключается предопределенный 404-файл.
Если сайт представляет собой сложный проект, то как правило используют роутинг на основе php-классов. Так его проще поддерживать и развивать. Если же сайт состоит из небольшого количества страниц, то как правило используют подключаемые файлы, где один файл — это одна страница.
Строго говоря, роутинг «на классах» тоже использует «файловое» подключение. Вначале подключается файл с кодом класса, а уже после этого выполняется сам класс.
В задачу роутинга входит не только необходимое «действие», но и валидация входящего адреса и его лексический разбор.
Свой «велосипед» не изобретал только ленивый, но я отмечу довольно известный FastRoute, который вобрал в себя наиболее типичные решения.
В первую очередь это использование регулярных выражений при задании правил, например:
Примерно такой же подход используется и в роутинге CodeIgniter.
То есть входящий адрес должен соответствовать шаблону и только в этом случае он «сработает».
В FastRoute реализована поддержка POST и GET-запросов. Такая возможность интересна, хотя на больших проектах такие вещи лучше делать на уровне самого «действия». Но это уже тонкости. Про эту библиотеку я упоминаю в первую очередь из-за того, что она достаточно популярна и уже используется в нескольких интересных проектах: Slim и Lumen.
Для небольших проектов, конечно же, FastRoute будет избыточна, поэтому можно ограничиться вариантом попроще, да и мозги потренировать. 🙂
Весь код в 2 строчки:
Это простой роутинг для простых проектов. Достаточно создать в content каталог, как он станет доступен по одноименному адресу.
PHP: Простой роутинг с помощью библиотеки PHRout
Сегодня я поделюсь с вами опытом как достаточно быстро и с минимальными трудозатратами можно создать свою систему маршрутизации (роутинга) в вашем php приложении. Поможет нам в этом замечательная библиотека PHRoute.
PHRoute — это отличная библиотека которая обеспечивает быструю реализацию маршрутизатора на основе регулярных выражений. В этом уроке мы рассмотрим, как его использовать в типовом проекте. Кроме того заглянем на его реализации в ядре, дабы лучше разобраться в вопросах маршрутизации.
Я подразумеваю что вы уже имеете представление о том как пользоваться композером, потому, что установку данной библиотеки мы будем осуществлять с помощью этого менеджера пакетов.
Итак приступим, создаём файл нашего проекта composer.json
Теперь из папки вашего проекта выполняем команду composer install. В корне должна пояаится папка Vendor.
Для лучшего понимания концепции PHRoute, неплохо бы создать образец проекта для работы. Сегодня мы сделаем с вами базовый API базы данных книг.
Вот схема базы данных, которую мы собираемся использовать:
Если вы хотите сделать некоторые тесты, это дамп схемы SQL, который я использовал (с некоторыми дополнительными фиктивными данными):
Не переживайте в этом уроке мы не будем писать излишне сложных конструкций. На самом деле достаточно написать всего пару-тройку маршрутов для эмуляции простейшего API, что бы просто разобратся как это работает. Для написания действительно сложного API вам необходимо будет изучить большое колличество концепций. В сегоднешнем-же уроке, мы просто хотим понять как работает PHRout.
Прежде чем мы начнем с конкретных маршрутов, давайте проанализируем основную структуру приложения. Это то, что мы собираемся добавить в наш файл index.php
У нас есть три служебных метода: processInput, processOutput и getPDOInstance. Мы будем использовать первые два, чтобы убедиться, что мы получаем правильный ввод и правильный вывод. Третий подготовит необходимый экземпляр PDO.
Как вы можете видеть, в этом конкретном примере мы объявили один маршрут: hello.
Приступим к созданию нашего первого роута! Давайте посмотрим, что мы можем делать с маршрутами, и насколько мы можем кастомизировать их для наших нужд.
Начинаем с самого простого: список авторов.
В первой строке мы указываем название нашего маршрута — authors. Проверим наш роут, если вы перейдёте по адресу: ваше_приложение/autors, должнен полуится вот такой вот массив данных:
Отлично! Теперь давайте попробуем добавить параметр, что бы получить все книги одного автора основываясь на его id.
Для этого ипользуем конструкцию на подобии этой:
Иногда параметр может быть необязательным. Давайте сделаем еще один пример: если мы используем URL books, мы хотим получить список всех книг базы данных. Но, если мы укажем id, как параметр, например: books/1, мы получим список книг по данной категории, вот так:
До сих пор мы создали только маршруты для GET запросов. Как насчет других HTTP запросов? Не вопрос! вот вам пример:
Давайте сделаем пример маршрута принимающего POST данные. Пришло время добавить новую книгу в нашу коллекцию!
Представим, что у нас есть форма для заполнения данными книги: её экшен содержит путь, который мы создали прямо сейчас, для приёма POST данных.
Теперь мы пойдём дальше: пришло время «защитить» наши маршруты! Сейчас выходит, что каждый кто передаст post данные по маршруту books сможет добавить данные в нашу базу данных. В серьёзных проектах это разумеется неопустимо. В этом случае нас выручат фильтры. Фильтры очень похожи на маршруты: у них есть имя и связанное с ним закрытие, которое выполняется, когда фильтр вызывается где либо.
Давайте разберёмся в чём разница? Фильтр можно легко вызвать до (или после) маршрута. Привожу пример:
Существует также ключ after, который используется для запуска фильтра сразу после вызова маршрута. Вот вам пример:
Если вам нужно, вы также можете указать несколько фильтров одновременно. Все, что вам нужно сделать, это использовать массив строк, а не одну строку.
Представим себе реальный мир: допустим, у нас есть три почтовых маршрута, по одному для каждой сущности (автор, книга, категория). Было бы печально добавлять фильтр logged_in три раза. К счастью нас готов выручить групповой фильтр:
С помощью этой единственной группы фильтров мы определили одни и те-же правила для трех разных маршрутов. Кстати, если вам нужно, вы можете вложить группы в другие группы столько раз, сколько необходимо для решения поставленной вами задачи.
Прежде всего, давайте посмотрим, как устроена структура нашего контроллера. Взгляните на этот пример (мы можем поместить его прямо в файл routes.php):
Итак, если мы введем URL автора в нашем браузере, метод getIndex() будет вызываться автоматически. То же самое относится к методу postAdd(), который будет привязан к URL-адресу author / add (POST).
Эта функция автоматического распознавания имён довольно интересна, но на самом деле её недостаточно.
Контроллер находится на ранней стадии разработки и нуждается во многих улучшениях. Одним из них является возможность определять параметры для методов контроллера. Или, может быть, простой способ определить фильтры для некоторых методов контроллера (а не «все или ничего»).
Заключение. Ещё многое нуждается в доработке, особенно на стороне контроллеров. Как разработчик, я думаю, было бы здорово иметь базовый базовый класс контроллера для обработки всей грязной работы (с фильтрами, параметрами методов и т. д.). К сожалению документация по данному вопросу отсутствует.
С другой стороны, PHRoute поставляется с очень быстрым маршрутизатором. На странице GitHub проекта, вы можете увидеть некоторые статистические данные о сравнении с основным маршрутизатором Laravel: результаты потрясающие. В худшем случае PHRoute примерно в 40 (да, 40) раз быстрее.
Быстрый роутинг на PHP
Мне не очень хотелось использовать конструкции, предлагаемые большинством фреймворков, в целом выглядящие в таком виде:
Изначально хотелось хранить правила роутинга в JSON или XML.
Однако парсить каждый раз файл не очень хорошая идея, и такой тип более пригоден для статической навигации или навигации вида /controller/action/.
Мне же хотелось большей гибкости в настройке роутинга и в конечном итоге решил использовать XML для хранения правил, а после парсинга файла и создания массива правил сериализовывать его в файл (в дальнейшем используя его для получения настроек)
XML-файл правил роутинга выглядит примерно так:
Структура правила представляет собой следующее
XML-элемент правил содержится в элементе /root/routes, элемент правил должен содержать в себе следующие атрибуты:
match — Используется для поиска по URL
controller — Вызываемый контроллер
action — Вызываемый метод
match может содержать как статические данные, например «secret», так и динамические «page-
В переменной можно указать её тип:
На основе XML формируется массив, который разделает статические и динамические правила.
Все потомки так же разделяются на статических и динамических.
Так же в элементе /root/system
хранятся следующие данные:
Соответственно в случае, если совпадения по правилам роутинга найдены не будут, вернётся 404 ошибка, в случае пустого урл — его index значение
Пример MVC в php. Вторая статья. Маршрутизация, контролеры, экшены, шаблоны и модели
Содержание цикла статей:
Теперь можно проверять работу перенаправления, введите любой адрес и посмотрите, что получиться: test-mvc.web/sdf/sdf/ или test-mvc.web/sdf/sdf/2342/не важно, на экране в любом случае, должно появиться «Test». Если Вы увидели эту надпись, значит, у нас все получилось.
Продолжим, давайте для удобства создадим в корне сайта файл config.php, в котором будем задавать различные константы, облегчающие своим существование настройку сайта. Это могут быть различные пути к скриптам, подступы к базе данных и так далее. Сейчас в конфиге давайте зададим следующее:
Класс хранилища Registry.php, будет находиться в папке /classes/
Код файла router.php, который находиться в папке /classes/
Теперь необходимо создать папки для хранения контроллеров, шаблонов и моделей – в корне создадим три папки controllers, views и models. И создадим несколько тестовых файлов /controllers/index.php, /views/index/index.php и /models/model_users.php, а теперь заполним файлы:
Для контроллера:
Как вы могли заметить, класс контролера наследуется от родительского класса Controller_Base. Это сделано, для того, чтобы упростить класс контролера. Поскольку нам еще необходимо подключать класс для работы с шаблонами, его подключение вынесено в Controller_Base.
Приведу его код, он расположен в папке /classes/ и называется controller_base.php :
Теперь осталось только разобраться с шаблонами. В абстрактном классе Controller_Base мы вызываем класс Template и передаем ему имя шаблона и имя контроллера.
Код класса Template, который лежит тут /classes/ и называется template.php
Если вы внимательно прочитали код, то наверняка поняли, что для отображения на страницах у нас используется шаблон first_layouts и вьюха(отображение) index.php – ее код я приводил чуть выше. Все что нам осталось, это создать файл шаблона first_layouts. Расположим его в папке /views/layouts/first_layouts.php
Шаблон будет содержать вот такой код:
Вот и все, на этом создание «каркаса» закончено. Сейчас у нас получилась самая простая структура, использующая в своей основе паттерн MVC. В этой статье я не стал затрагивать работу с базой данных, только вскользь упомянул ее, поскольку статья и так получилась большая. Непосредственно работу с базой данных я опишу в следующей статье.
На этом статья закончена, скачать исходники можно архивом тут.
ЧПУ, роутинг, единая точка входа на PHP
Единая точка входа
Принцип работы единой точки входа очень прост.
Вот и весь принцип единой точки входа. Именно так она работает в популярных CMS вроде WordPress и Opencart, в фреймворках Laravel, Symfony и т.д.
Лично я предпочитаю также перенаправлять их на index.php.
На самом деле на сайтах часто используются 2 точки входа.
Плюсы единой точки входа
Единая точка входа с Apache
Этот файл позволяет переопределять настройки Apache для определённых сайтов и папок.
Также в интернете часто можно встретить другой вариант конфига, отличается он только последней строкой:
Единая точка входа с Nginx
Открываем конфиг домена и внутри секции server прописываем следующее правило:
Простой роутинг
Если единая точка входа настроена правильно, то при заходе по любому несуществующему URL-адресу, например /test должен запуститься файл index.php.
Теперь мы можем написать очень простой роутер, который смотрит на текущий URL и подключает соответствующий скрипт:
Внесём ещё пару доработок. Во-первых, зачастую URL-адреса должны работать вне зависимости от наличия GET-параметров, поэтому вырежем их из URI:
Кроме этого, часто требуется получить доступ к определённой части URL. Для этого разобьём URL на части по слешу:
Теперь мы можем легко добавить маршруты для админки:
Это самый простой вариант роутинга. Не идеальный, конечно, но и не требующий знания регулярных выражений (хотя никто не мешает их использовать) и подключения сторонних библиотек.
При хранении URL адресов в базе данных роутинг будет выглядеть примерно так (реальный код зависит от библиотеки, которую вы используете для взаимодействия с БД):
Роутинг средствами htaccess
Какое-то время назад было популярно прописывать правила роутинга прямо в htaccess, вот несколько примеров:
У этого подхода есть несколько недостатков:
Короче, не используйте этот подход.
Структура URL адресов в админке
Обычно URL адреса в админке формируются по одной из следующих схем:
И сразу рассмотрим простой пример:
Перепишем пример, написанный нами в единой точке входа, под новую схему URL:
Итак, мы берём 1-ый фрагмент URL и проверяем, существует ли в папке pages файл с таким названием.
Как видите, при таком подходе нам больше не нужно прописывать соответствие URL-адресов и PHP-файлов. PHP сам будет искать нужный файл в папке pages по первому фрагменту URL.
Вот так выглядит обработка действий. Мы смотрим на второй фрагмент URL и ищем обработчик этого действия. Для каждого действия (add, update, delete) нужно прописать отдельный блок elseif.
Если вам не нравится вложенная проверка метода, можно сделать иначе. В файле index.php сохраним метод в отдельную переменную:
Затем в products.php меняем заготовку на следующую:
Готово. Да, если вам не нравится, что в коде 2 раза встречается одно и то же действие, только с разными методами, можете использовать немного упрощённую схему URL-адресов из фреймворка Laravel:
Добавление префикса /admin/ в URL
Немного изменим код index.php :
Продвинутый роутер FastRoute
Если вы ищете более серьёзную систему роутинга, рекомендую изучить библиотеку FastRoute. Это очень мощный роутер, идеально подходящий для сложных приложений, особенно если вы используете ООП.