Маршрутизация
Наш первый пример было не так уж трудно проглотить, не так ли?
Вставьте другой маршрут перед командой $f3->run()
:
Вы же не хотите загромождать глобальное пространство имен, именами функций? Fat-Free распознает различные способы сопоставления обработчиков маршрутов с классами и методами ООП:
HTTP-запросы также могут быть перенаправлены в статические методы класса:
Застряли с ошибкой 404? Проверьте конфигурацию вашего сервера.
Маршруты и токены
В качестве демонстрации мощного доменного языка Fat-Free (DSL) вы можете указать один маршрут для обработки различных вариантов:
Этот пример показывает, как мы можем указать токен @count
для представления части URL-адреса. Фреймворк будет обслуживать любой URL-адрес запроса, соответствующий префиксу /brew/
, например /brew/99
, /brew/98
и т. д. Это будет отображать "99 бутылок пива на стене"
и "98 бутылок пива на стене"
, соответственно.
Fat-Free также примет приглашение на странице /brew/небьющиеся
.
(Ожидайте, что это покажет "небьющиеся бутылки пива на стене".) Когда такой динамический маршрут задан, Fat-Free автоматически заполняет глобальную переменную массива PARAMS
значением захваченных строк в URL-адресе. Вызов $f3->get()
внутри функции обратного вызова извлекает значение переменной фреймворка. Вы, конечно, можете применить этот метод в своем коде как часть презентации или бизнес-логики. Но мы обсудим это более подробно позже.
Обратите внимание, что Fat-Free понимает точечную нотацию массива. Вместо этого в коде можно использовать обычную нотацию PARAMS['count']
, которая подвержена ошибкам опечаток
и несбалансированным фигурным скобкам. В представлениях и шаблонах фреймворк допускает @PARAMS.count
графическая нотация, которая несколько похожа на Javascript. (Мы рассмотрим представления и шаблоны позже.)
Вот еще один способ доступа к токенам в шаблоне запросов:
Вы можете использовать звездочку (*
), чтобы принять любой URL-адрес после маршрута /brew
- если вас действительно не волнует остальная часть пути:
Важный момент для рассмотрения: вы запутаете Fat-Free (и себя), если у вас есть оба GET /brew/@count
и GET /brew/*
вместе в одном приложении. Используйте одно или другое. Другое дело: Fat-Free видит GET /brew
как отдельный и отличный от маршрута GET /brew/@count
. Каждый из них может иметь различные обработчики маршрутов.
Важно: все обработчики маршрутов автоматически передают экземпляр фреймворка и токены маршрута. Смотреть здесь.
Именованные Маршруты
Когда вы определяете маршрут, вы можете присвоить ему имя. Используйте имя маршрута в своем коде и шаблонах вместо введенного url-адреса. Затем, если вам нужно изменить свои URL-адреса, чтобы угодить маркетинговым властелинам, вам нужно только сделать изменение там, где был определен маршрут. Имена маршрутов должны соответствовать правилам именования переменных php (без точек, тире и дефисов).
Давайте назовем маршрут:
Имя вставляется после запроса маршрута (GET
в этом примере), предшествующего символу @
, и отделяется от части URL двоеточием :
символ. Вы можете вставить пробел после двоеточия, если это облегчает чтение вашего кода (как показано здесь).
Чтобы перенаправить посетителя на новый URL-адрес, вызовите именованный маршрут внутри метода reroute()
, например:
Если вы используете токены в своем маршруте, F3 заменит эти токены их текущим значением. Если вы хотите изменить значение токена перед вызовом reroute, передайте его в качестве 2-го аргумента:
Не забудьте указать urlencode()
ваши аргументы, если у вас есть символы, которые
не соответствуют рекомендациям RFC 1738 для хорошо сформированных URL - адресов.
Именованные маршруты в шаблонах
Чтобы получить доступ к именованному маршруту в шаблоне, можно передать имя маршрута в фильтр псевдонимов:
Если вы хотите построить ссылку на именованный маршрут, содержащий токены, вы можете передать дополнительные параметры в фильтр псевдонимов:
Это также работает с переменными, которые выглядят как {{ @name, 'a=5,b='.@id | alias }}
. Вам нужно только установить или перезаписать токены в именованных маршрутах, которые вам нужно изменить. Все остальные токены заполняются автоматически, исходя из текущего маршрута.
Если вам нужно заменить токены подстановочных знаков в вашем маршруте
(т. е. GET @complex:/resize/@format/*/sep/*)
, используйте числовой индекс, чтобы указать его новое значение, например: {{'complex','format=20x20,2=foo/bar,3=baz.gif'|alias}}
.
Чтобы создать URL-адреса в коде контроллера, см. раздел псевдоним и методы сборки.
Динамические Веб-Сайты
Подождите секунду - во всех предыдущих примерах мы никогда по-настоящему не создавали каталог на нашем жестком диске для хранения этих маршрутов. Короткий ответ: мы не должны этого делать. Все маршруты F3 являются виртуальными. Они не отражают нашу структуру папок на жестком диске. Если у вас есть программы или статические файлы (изображения, CSS и т. д.) которые не используют фреймворк - до тех пор, пока пути к этим файлам не конфликтуют с каким - либо маршрутом, определенным в вашем приложении-ваше программное обеспечение веб-сервера доставит их в браузер пользователя, если сервер настроен правильно.
Встроенный веб-сервер PHP 5.4 Последняя стабильная версия PHP имеет свой собственный встроенный веб-сервер. Запустите его, используя следующую конфигурацию:
Приведенная выше команда начнет маршрутизацию всех запросов в web root /var/www
. Если поступит входящий HTTP-запрос на файл или папку, PHP будет искать его в корне веб-сайта
и отправлять в браузер, если он будет найден. В противном случае PHP загрузит индекс по index.php
(содержащий ваш код с поддержкой F3).
Пример Конфигурации Apache Если вы используете Apache, убедитесь, что вы активировали модуль перезаписи URL - адресов (mod_rewrite) в вашем apache.conf (или httpd.conf) файл. Вы также должны создать файл .htaccess, содержащий следующее:
Скрипт сообщает Apache, что всякий раз, когда приходит HTTP-запрос и если нет физического файла (!-f
) или путь (!-d
) или символическая ссылка (!-l
) можно найти, он должен передать управление index.php
, который содержит наш главный / фронт контроллер, и который, в свою очередь, вызывает фреймворк.
То файл .htaccess
, содержащий указанные выше директивы Apache, всегда должен находиться в той же папке, что и index.php
.
Вам также нужно настроить Apache, чтобы он знал физическое местоположение index.php
на вашем жестком диске. Типичная конфигурация-это:
Приказ разрешить, запретить Разрешить от всех </Справочник> В случае, если вы просто помещаете свой обезжиренный проект в подпапку существующего корневого документа, некоторые конфигурации Apache, возможно, также нуждаются в определенной RewriteBase
перезаписи .файл .htaccess
. Если приложение не работает или маршрут по умолчанию
/
работает, но /test
, возможно, не работает, попробуйте добавить базовый путь:
Если вы разрабатываете несколько приложений одновременно, управлять конфигурацией виртуального хоста будет проще:
Каждое ServerName
(site1.com
и еще site2.com
в нашем примере) должен быть указан
в вашем файле /etc/hosts
. В Windows вы должны отредактировать C:/WINDOWS/system32/drivers/etc/hosts
-да. Для осуществления изменений может потребоваться перезагрузка компьютера. Затем вы можете направить свой веб-браузер
по указанному адресу http://site1.com
или http://site2.com
виртуальные хосты значительно облегчают развертывание ваших приложений.
Альтернативная конфигурация Apache
Если mod_rewrite
недоступен на вашем сервере или вы хотите немного повысить производительность, вы можете воспользоваться директивой FallbackResource, доступной
в Apache 2.4 и выше.
В таком случае просто добавьте следующую строку в свой список .файл .htaccess
или в вашей конфигурации VirtualHost:
Если ваше веб-приложение работает в подпапке корневого сервера, не забудьте соответствующим образом изменить директиву:
Обратите внимание: в настоящее время существует ошибка, которая пропускает директиву, когда запрашиваемый URI заканчивается .php и находится в корне приложения: http://localhost/fatfree-project/foo.php = > ошибка 404 http://localhost/fatfree-project/foo/bar.php = > OK
Пример Конфигурации Nginx
Для серверов Nginx вот рекомендуемая конфигурация (замените ip_address: port настройками PHP FastCGI вашей среды):
Пример Конфигурации
Документации Сервера конфигурационный файл lighttpd настраиваются аналогичным образом:
Пример конфигурации IIS
Установите модуль перезаписи URL-адреса и соответствующую платформу .NET framework, соответствующую Вашей версии Windows. Затем создайте файл с именем web.config в корневом каталоге приложения со следующим содержимым:
Изменение маршрута
Так что давайте вернемся к кодированию. Вы можете объявить страницу устаревшей и перенаправить посетителей на другой сайт:
а это то же самое, что и
Если кто-то попытается получить доступ к URL-адресу http://www.example.com/obsoletepage
используя HTTP GET или HEAD request, фреймворк перенаправляет пользователя на URL-адрес: http://www.example.com/newpage
как показано в приведенном выше примере. Вы также можете перенаправить пользователя на другой сайт, например $f3->reroute('http://www.anotherexample.org/');
.
Перенаправление может быть особенно полезно, когда вам нужно выполнить некоторые работы по техническому обслуживанию на вашем сайте. У вас может быть обработчик маршрута, который информирует ваших посетителей о том, что ваш сайт находится в автономном режиме в течение короткого периода времени.
Http-редиректы незаменимы, но они также могут быть дорогостоящими. Насколько это возможно, воздержитесь от использования $f3->reroute()
для отправки пользователя
на другую страницу того же веб-сайта, если вы можете направить поток вашего приложения, вызвав функцию или метод, который обрабатывает целевой маршрут. Однако этот подход
не изменит URL-адрес в адресной строке веб-браузера пользователя. Если это не то поведение, которое вы хотите, и вам действительно нужно отправить пользователя на другую страницу,
в таких случаях, как успешная отправка формы или после аутентификации пользователя,
Fat-Free отправляет заголовок HTTP 302 Found
. Для всех других попыток перенаправить
на другую страницу или сайт фреймворк отправляет заголовок HTTP 301 Moved Permanently
.
Ошибки 404
Во время выполнения Fat-Free автоматически генерирует ошибку HTTP 404 всякий раз, когда видит, что входящий HTTP-запрос не соответствует ни одному из маршрутов, определенных в вашем приложении. Однако бывают случаи, когда вам нужно вызвать его самостоятельно.
Возьмем, к примеру, маршрут, определенный как GET /dogs/@breed
. Логика вашего приложения может включать поиск в базе данных и попытку получить запись, соответствующую значению @breed
во входящем HTTP-запросе. Поскольку Fat-Free будет принимать любое значение после префикса /dogs/
из-за наличия токена @breed
, отображение сообщения HTTP 404 Not Found
программно становится необходимым, когда программа не находит никакого соответствия
в нашей базе данных. Для этого используйте следующую команду:
ReST: Передача состояния представления
Fat-Free основана на концепции, что HTTP URI представляют собой абстрактные веб-ресурсы (не ограничиваясь HTML), и каждый ресурс может перемещаться из одного состояния приложения в другое. По этой причине F3 не имеет никаких ограничений на то, как вы структурируете свое приложение. Если вы предпочитаете использовать шаблон Model-View-Controller, F3 может помочь вам разделить компоненты приложения, чтобы придерживаться этой парадигмы. С другой стороны, фреймворк также поддерживает шаблон представления ресурсов-методов, и его реализация более проста.
Вот пример интерфейса ReST:
Метод Fat-Free $f3->map()
предоставляет интерфейс ReST путем сопоставления HTTP-методов
в маршрутах с эквивалентными методами объекта или класса PHP. Если ваше приложение получает входящий HTTP-запрос типа GET /cart/123
, Fat-Free автоматически передаст управление методу get()
объекта или класса. Аналогично, запрос POST /cart/123
будет перенаправлен в метод класса элементов post()
.
Сопоставленные методы могут быть префиксированы с помощью переменной PREMAP.
Примечание: браузеры не реализуют методы HTTP PUT
и DELETE
в обычных HTML-формах. Эти и другие методы ReST (HEAD
и CONNECT
) доступны только через AJAX-вызовы на сервер. Однако они могут быть туннелированы через POST
запрос, установив параметр _method
в нужный http-глагол.
Если фреймворк получает метод HTTP, который не реализован классом, он генерирует ошибку HTTP 405 Method Not Allowed
. F3 автоматически реагирует с соответствующими заголовками, параметры HTTP OPTIONS
методом. Фреймворк не будет сопоставлять этот запрос классу.
Обратите внимание: если вы планируете построить целый REST API, вам, вероятно, нужно обойти возможность извлечения отдельных элементов, целых коллекций элементов и сохранения и обновления записей, которые не всегда вписываются в один класс или заданные методы HTTP. Всегда лучше планировать свой API, прежде чем приступать к кодированию. Вот очень хорошая и бесплатная электронная книга о дизайне веб-API от apigee, которая может быть полезна.
Автопогрузчик F3
Fat-Free имеет возможность загружать классы только в то время, когда они вам нужны, поэтому они не поглощают больше памяти, чем требуется конкретному сегменту вашего приложения.
И вам не нужно писать длинный список операторов include
или require
только для загрузки классов PHP, сохраненных в разных файлах и разных местах. Фреймворк может сделать это автоматически для вас. Просто сохраните файлы классов (по одному классу на файл) в папке (например, "myclassfiles") и установите переменную autoload, указывающую на эту папку:
Важно: имя класса и имя файла должны быть идентичны, чтобы фреймворк мог автоматически загружать ваш класс. Если ваш класс называется BarBaz
, ваш файл должен быть назван BarBaz.php
. barbaz.php
в нижнем регистре тоже будет работать.
Когда вы вызываете свой класс или метод с помощью $obj=new Barbaz;
, Fat-Free Framework будет искать файл barbaz.php в пути(путях), указанном в переменной autoloader. Как только он найдет файл, он будет включать в себя использование команды require
PHP. Вот как работает автоматическая загрузка.
Путь автоматической загрузки ищется из расположения вашего index.php файла. Вы можете установить свою переменную AUTOLOAD
, используя абсолютный путь, т. е. /var/www/mywebsite.com/myclassfiles/
или используя относительный путь, как видно из расположения вашего индекса.PHP-файл ../myclassfiles/
, когда index.php находится в файле /var/www/mywebsite.com/
.
Вы также можете иметь несколько путей автоматической загрузки. Если ваши классы разделены на разные папки, вы можете поручить фреймворку автоматически загружать соответствующий класс при вызове статического метода или при создании экземпляра объекта. Измените переменную AUTOLOAD
, чтобы она указывала на несколько папок:
Работа с пространствами имен
AUTOLOAD
позволяет иерархиям классов находиться в подпапках с аналогичными именами, поэтому, если вы хотите, чтобы фреймворк автоматически загружал класс пространства имен, который вызывается следующим образом:
Вы можете создать иерархию папок, которая следует той же структуре. Предполагая, что /var/www/html/
является веб-корень, затем F3 будет выглядеть для класса в /var/www/html/autoload/gadgets/ipad.php
. Файл ipad.php
должен иметь следующий минимальный код:
Помните: все названия каталогов в Fat-Free должны заканчиваться косой чертой. Вы можете назначить путь поиска для загрузчика следующим образом:
NB: пространства имен здесь, чтобы помочь вам организовать свой код. Если вы используете их, вы можете решить, делать это с помощью F3 autoloader или нет. Если вы используете автозагрузчик, вам нужно создать папку для каждого пространства имен. Если вы не используете автозагрузчик, вы можете хранить свои файлы так, как вам нравится, имея в виду, что вам нужно будет включить каждый из них вручную.
Маршрутизация к классу пространства имен
F3, будучи фреймворком, ориентированным на пространство имен, позволяет использовать метод в классе namespaced в качестве обработчика маршрута, и есть несколько способов сделать это. Вызов статического метода:
Приведенный выше код вызовет метод static show()
класса Home
в основном пространстве имен. Home
класс должен быть сохранен в папке classes/main/home.php
для того, чтобы он загружался автоматически.
Если вы предпочитаете работать с объектами:
будет создан экземпляр Home
класса во время выполнения и после этого вызовет метод show()
.
Обработка корпуса автопогрузчика
В системах, чувствительных к регистру, таких как UNIX, класс автоматически загружается только в том случае, если файл класса и путь имеют тот же регистр, что и класс пространства имен, или если они строчные. Например:
Если класс подгружаться Main\Home
, можно имена Main/Home.php
или main/home.php
. ⇒ main\Home.php
, Main\hoME.php
или MAIN\HOME.php
не будет загружаться!
Если вам нужно определить пользовательскую обработку обращений, вы можете установить переменную AUTOLOAD
в виде массива пути и пользовательской функции. Допустим, что все ваши имена файлов прописные. Тогда вместо определения $f3->set('AUTOLOAD','classes/'
,
вы должны определить:
Обработчик событий
В F3 есть несколько прослушивателей событий маршрутизации, которые могут помочь вам улучшить поток и структуру классов контроллеров. Допустим, у вас есть маршрут, определенный следующим образом:
Если приложение получает HTTP-запрос, соответствующий указанному выше маршруту, F3 сначала создает экземпляр Main
, но перед выполнением метода home()
фреймворк ищет метод в этом классе с именем beforeRoute()
. Если он присутствует, F3 запускает код, содержащийся в обработчике событий beforeRoute()
, перед передачей управления методу, указанному в маршруте, в нашем примере методу home()
. После завершения работы метода фреймворк ищет обработчик событий afterRoute()
, который вызывается, если он присутствует. Обработчики событий beforeroute()
и afterroute()
являются общими для данного класса. Это означает, что если вы определили по разным маршрутам с использованием различных методов этого же класса, например, 'GET /login','User->login'
и 'GET /logout','User->logout'
, обе стороны будут одинаковыми beforeroute()
и afterroute()
обработчики событий.
Создайте функции beforeRoute()
и afterRoute()
в базовом классе контроллера и попросите
их применяться к каждому запросу. Конечно, вы можете переопределить их в дочерних контроллерах, определив пользовательские обработчики beforeRoute()
и afterRoute()
в дочерних классах. Можно также создать beforeRoute()
и afterRoute()
в дочернем классе
и наследовать обработчики переднего контроллера, вызывая parent::beforeRoute();
или parent::afterRoute();
в дочерних классах.
Динамические Обработчики Маршрутов
Вот еще один F3 сюрпризом:
Если ваше приложение получает запрос, скажем, на /products/itemize
, F3 извлекает строку 'itemize'
из URL-адреса и передает ее маркеру @action
в обработчике маршрута. Затем F3 будет искать класс с именем Products
и выполнять его метод itemize()
.
Динамические обработчики маршрутов могут иметь различные формы:
F3 вызывает ошибку HTTP 404 Not Found
во время выполнения, если он не может передать управление классу или методу, связанному с текущим маршрутом, т. е. нет определенного класса и/или метода, соответствующего запрошенному маршруту.
AJAX и синхронные запросы
Шаблоны маршрутизации могут содержать модификаторы, которые предписывают фреймворку основывать свое решение о маршрутизации на типе HTTP-запроса:
Первый оператор перенаправит HTTP-запрос на обратный вызов Page->getFragment()
только
в том случае, если сервер получит заголовок X-Requested-With: XMLHttpRequest
(объект AJAX). Если обнаружен обычный (синхронный) запрос, F3 просто опустится до следующего совпадающего шаблона, и в этом случае он выполняет обратный вызов Page->getFull()
.
Если в шаблоне маршрутизации не определены модификаторы, то к указанному обработчику направляются как AJAX, так и синхронные типы запросов.
Модификаторы шаблона маршрута также распознаются $f3->map()
.
Маршрутизация в режиме CLI
Веб-синтаксис Если вы хотите запустить определенный маршрут из инструмента командной строки, сценария оболочки, консоли или задания cron, вы можете эмулировать запрос HTTP GET следующей командой:
NB: строки запросов также поддерживаются:
Shell синтаксис Вместо запроса URI вы можете передать аргументы и параметры оболочки. Они будут автоматически преобразованы в эмулированный HTTP GET запрос, что позволяет легко создавать инструмент оболочки точно так же, как вы бы создавали веб-приложение.
Для преобразования применяются следующие правила сопоставления:
аргументы, разделенные пробелами, сопоставляются компонентам пути параметры short-form (aka flags) и long-form сопоставляются со строковыми аргументами запроса варианты короткой формы могут быть объединены параметры могут передаваться в любом порядке (до, Между или после аргументов) Вот несколько примеров:
php index.php test
соответствуетGET /test
php index.php log show --limit=50 --full
соответствуетGET /log/show?limit=50&full=
php index.php cache clear -f -v -i -n=23
соответствуетGET /cache/clear?f=&v=&i=&n=23
все ниже перечисленное эквивалентно предыдущему запросу:
php index.php cache clear -fvi -n=23
php index.php cache clear -fvin=23
php index.php cache -fvin=23 clear
php index.php -fvin=23 cache clear
php index.php -fvi cache clear -n=23
Параметры CLI доступны через глобальную переменную $_GET
.
Вот два слегка отличающихся подхода к вариантам обработки:
Определение маршрутов Маршруты CLI определяются так же, как и веб-маршруты, с той лишь разницей, что они могут быть ограничены режимом CLI с помощью модификатора [cli]. Например:
Примечание: переменная Кинк говорит, если запрос приходит из командной строки или нет.
Осмеяние Маршруты CLI можно высмеивать так же, как и веб-маршруты. Остерегайтесь, что синтаксис оболочки здесь не разрешен:
Last updated