В современных web-приложениях принято использовать концепцию единой точки входа. Эта концепция сводится к тому, что все запросы к серверу приложения переадресовываются на один файл, который, исходя из параметров запроса, координирует дальнейшее поведение скрипта. Такой подход дает огромные преимущества, как на этапе создания, так и на этапе поддержки проекта, так как кардинально уменьшается избыточность кода, а для приложений, манипулирующих динамическим контентом, единая точка входа — это единственное правильное решение.
Приведенные примеры актуальны для конфигурации web-сервера apache.
Концепция единой точки входа в реализации сводится к тому, что необходимо указать web-серверу перенаправлять все поступающие к нему запросы к файлу, который будет нашей единственной точкой входа, пусть к примеру это будет файл index.php в корневой директории приложения. Для этих целей у web-сервера Apache есть директива RewriteRule, находящаяся в модуле mod_rewrite. Синтаксис директивы следующий:
Шаблон — это perl-совместимое регулярное выражение, которое применяется к текущему URL, причем под текущим подразумевается значение URL в момент применения этого правила. Этот URL не обязательно совпадает с первоначально запрошенным URL, потому что до этого момента возможно уже были применены другие правила к этому URL и соответственно преобразовали его.
Подстановка — это строка, которая будет заменять оригинальный URL, для которого есть совпадение Шаблону. Кроме текста в подстановке можно использовать много чего, но нас интересуют пока только лишь переменная сервера REQUEST_URI.
Из флагов воспользуемся лишь двумя — QSA и L. Первый указывает механизму преобразований на то, что нужно добавить, а не заменить, строку запроса из URL к существующей, в строке подстановки. Флаг L указывает серверу остановить процесс преобразования на этом месте и не применять больше никаких правил преобразований.
Учитывая все выше сказанное, допишем в файл .htaccess в корневой директории приложения следующую строку:
Но не следует забывать о том, что кроме обращения непосредственно к скрипту, браузер будет запрашивать у сервера различные файлы ресурсов, такие как каскадные таблицы стилей, изображения, файлы со скриптами и т.п. Для того, чтобы сервер дал доступ браузеру к желаемому, нужно задать дополнительные условия директиве RewriteRule. Эти условия описываются директивой RewriteCond, которая определят когда следует делать преобразования в URL или когда необходимо оставить его без изменений.
Не вдаваясь глубоко в подробности, приведу несколько примеров, а более подробно об упомянутых директивах можно прочитать по ссылкам приведенным в конце статьи.
Смотря на приведенные строки, можно сразу заметить, что в них происходит сравнение REQUEST_URI со строкой, описанной perl-совместимым регулярным выражением, и в случае совпадения, подмены URL не происходит.
Примечание: Нужно не забывать о том, что все директивы RewriteCond должны быть описаны до использования RewriteRule.
Описанный выше способ — лишь один из возможных, рассмотрим как реализована концепция в Zend Framework.В предыдущем примере предполагалось, что точка входа находится в корневом каталоге веб-приложения, предлагаемая по умолчанию структура проекта на базе Zend Framework отличается тем, что каталог для общего доступа вынесен на уровень ниже, по умолчанию его имя public и доступ к веб-приложению настраивается таким образом, чтобы каталог public был корнем приложения, т.е. для получения доступа к ресурсам, находящимся вне директории public, в скрипте необходимо использовать условную адресацию для возврата на уровень выше либо же абсолютную адресацию, что вовсе не удобно, можно поступить например следующим образом:
Осталось написать содержимое файла public/.htaccess:
Используя описанный подход, отпадает необходимость задавать определенные права доступа к публичным ресурсам приложения, теперь нам достаточно просто поместить их в директорию public и доступ к ним будет предоставлен автоматически, а доступ к файлам-скриптам приложения, находящимся вне public будет закрыт.
Документация к модулю mod_rewrite
Приведенные примеры актуальны для конфигурации web-сервера apache.
Концепция единой точки входа в реализации сводится к тому, что необходимо указать web-серверу перенаправлять все поступающие к нему запросы к файлу, который будет нашей единственной точкой входа, пусть к примеру это будет файл index.php в корневой директории приложения. Для этих целей у web-сервера Apache есть директива RewriteRule, находящаяся в модуле mod_rewrite. Синтаксис директивы следующий:
RewriteRule Шаблон Подстановка ФлагиШаблон — это perl-совместимое регулярное выражение, которое применяется к текущему URL, причем под текущим подразумевается значение URL в момент применения этого правила. Этот URL не обязательно совпадает с первоначально запрошенным URL, потому что до этого момента возможно уже были применены другие правила к этому URL и соответственно преобразовали его.
Подстановка — это строка, которая будет заменять оригинальный URL, для которого есть совпадение Шаблону. Кроме текста в подстановке можно использовать много чего, но нас интересуют пока только лишь переменная сервера REQUEST_URI.
Из флагов воспользуемся лишь двумя — QSA и L. Первый указывает механизму преобразований на то, что нужно добавить, а не заменить, строку запроса из URL к существующей, в строке подстановки. Флаг L указывает серверу остановить процесс преобразования на этом месте и не применять больше никаких правил преобразований.
Учитывая все выше сказанное, допишем в файл .htaccess в корневой директории приложения следующую строку:
RewriteRule ^(.*)$ index.php?%{REQUEST_URI} [QSA,L]Но не следует забывать о том, что кроме обращения непосредственно к скрипту, браузер будет запрашивать у сервера различные файлы ресурсов, такие как каскадные таблицы стилей, изображения, файлы со скриптами и т.п. Для того, чтобы сервер дал доступ браузеру к желаемому, нужно задать дополнительные условия директиве RewriteRule. Эти условия описываются директивой RewriteCond, которая определят когда следует делать преобразования в URL или когда необходимо оставить его без изменений.
Не вдаваясь глубоко в подробности, приведу несколько примеров, а более подробно об упомянутых директивах можно прочитать по ссылкам приведенным в конце статьи.
RewriteCond %{REQUEST_URI} !^\/resources/styles/(.*).cssRewriteCond %{REQUEST_URI} !^\/resources/images/(.*).pngRewriteCond %{REQUEST_URI} !^\/resources/images/(.*).jpgRewriteCond %{REQUEST_URI} !^\/resources/lib/jquery/(.*).jsСмотря на приведенные строки, можно сразу заметить, что в них происходит сравнение REQUEST_URI со строкой, описанной perl-совместимым регулярным выражением, и в случае совпадения, подмены URL не происходит.
Примечание: Нужно не забывать о том, что все директивы RewriteCond должны быть описаны до использования RewriteRule.
Описанный выше способ — лишь один из возможных, рассмотрим как реализована концепция в Zend Framework.В предыдущем примере предполагалось, что точка входа находится в корневом каталоге веб-приложения, предлагаемая по умолчанию структура проекта на базе Zend Framework отличается тем, что каталог для общего доступа вынесен на уровень ниже, по умолчанию его имя public и доступ к веб-приложению настраивается таким образом, чтобы каталог public был корнем приложения, т.е. для получения доступа к ресурсам, находящимся вне директории public, в скрипте необходимо использовать условную адресацию для возврата на уровень выше либо же абсолютную адресацию, что вовсе не удобно, можно поступить например следующим образом:
Таким образом мы получили константу, содержащую относительный путь к логическому корню нашего приложения.define( 'DIR_SEPARATOR ', '/' ); define( 'ROOT', '..' . DIR_SEPARATOR );
Осталось написать содержимое файла public/.htaccess:
RewriteCond %{REQUEST_FILENAME} -s [OR]RewriteCond %{REQUEST_FILENAME} -l [OR]RewriteCond %{REQUEST_FILENAME} -dRewriteRule ^.*$ - [NC,L]RewriteRule ^.*$ index.php [NC,L]Используя описанный подход, отпадает необходимость задавать определенные права доступа к публичным ресурсам приложения, теперь нам достаточно просто поместить их в директорию public и доступ к ним будет предоставлен автоматически, а доступ к файлам-скриптам приложения, находящимся вне public будет закрыт.
Документация к модулю mod_rewrite
