Большинство URL-адресов в Invision Community являются "дружественными", также известные как FURLs (ЧПУ – человекопонятные ссылки) - то есть, они на простом английском и легко читаются пользователями и поисковыми системами. FURL (ЧПУ) отображаются с помощью Invision Community в виде традиционных URL с параметрами, на основе преобразования, предоставляемого приложением.
Например, FURL site.ru/messenger/compose может быть отображен как site.ru/index.php?app=core&module=messaging&controller=messenger&do=compose.
Как загружаются контроллеры
Контроллеры автоматически запускаются, когда совпадает URL. Параметры URL используются Invision Community, чтобы найти нужный контроллер:
app=core
Указывает, что контроллер находится в приложении “core”
module=messaging
Указывает, что контроллер находится в модуле обмена сообщениями “messaging”, в базовом приложении “core”
controller=messenger
Указывает, что мы загружаем контроллер “messenger”, в модуле обмена сообщениями “messaging”, в базовом приложении “core”
do=сompose
Параметр do не является обязательным, и позволяет вызывать конкретный метод в контроллере, чтобы обработать запрос. Если этот параметр опущен, то по умолчанию будет вызываться метод manage.
Так, для URL site.ru/index.php?app=core&module=messaging&controller=messenger&do=compose, загружаемый контроллер будет находиться в /applications/core/modules/front/messaging/messenger.php, и будет вызываться метод compose внутри контроллера, чтобы обработать запрос.
По этой структуре очень легко определить, какой именно способ, в каком контроллере обрабатывает запрос для любого заданного URL.
Определение дружественных URL-адресов
При разработке приложения, ваша FURL конфигурация создается в файле furl.json в каталоге /data вашего приложения. JSON структура определяет дружественный URL, реальный URL, который ему соответствует, и некоторые другие данные которые могут быть использованы.
Простой пример FURL
...
"messenger_compose": {
"friendly": "messenger/compose",
"real": "app=core&module=messaging&controller=messenger&do=compose"
},
...
Ключ (в данном случае messenger_compose) это то, что идентифицирует этот FURL в IPS4. При создании ссылок в шаблонах или контроллерах, вы будете использовать этот ключ, чтобы указать, какой FURL будет использоваться для генерации и парсинга URL-адреса.
Значение friendly это ЧПУ, который будут видеть пользователи. Значение real является фактическим URL, который будет использовать Invision Community, чтобы найти правильное app/module/controller для обработки запроса.
FURLs с использованием параметров
Хотя многие FURL статичные и простые, как в вышеуказанном примере, некоторые будут динамическими и будут включать в себя параметры, идентифицирующие конкретную запись, которая должна отображаться - например, просмотр темы на форуме. Для облегчения этой задачи, FURL определения поддерживают параметры.
...
"profile": {
"friendly": "profile/{#id}-{?}",
"real": "app=core&module=members&controller=profile"
},
...
Параметры, находящиеся внутри FURL заключены в фигурные скобки {}. Первый символ может быть либо #, чтобы соответствовать номеру, или @, чтобы соответствовать строкам. За этим следует имя параметра, и оно должно совпадать с именем параметра, который будет подставлен в реальном URL. Например, здесь мы используем {#id}, который совпадает с номером и приведет к &id=123 и передается в наш реальный URL.
Тег {?} может быть использован для SEO заголовков; то есть дружественный текст, который идентифицирует отдельные записи, но который не является частью реального URL. Примером этого было бы название темы - оно включено в URL, чтобы помочь пользователям и поисковым системам, но только id темы используется для её поиска в реальном URL-адресе.
Вы можете использовать несколько SEO заголовков в пределах URL, используя нулевой индексированный номер в теге, например {?0}, {?1} и {?2}.
Вам не следует указывать FURL параметры, которые вы собираете в реальном URL; они автоматически добавляются к реальному URL-адресу диспетчером. В приведенном выше примере URL пользователь будет видеть что-то вроде site.ru/profile/123-имя-пользователя.
Специфика FURL
Порядок, в котором вы указываете ваши FURL значения имеет большое значение. Когда диспетчер пытается соотнести URL, он проходит последовательно через значения FURL, и останавливается на первом значении, которое подходит. Отсюда следует, что ваши более специфичные значения должны идти перед менее специфичными в furl.json.
Например, предположим, у нас есть два значения, относящиеся к профилю пользователя. Одним из них является домашняя страница профиля, другой – страница редактирования профиля. Если мы указали значения таким образом:
"profile": {
"friendly": "profile/{#id}-{?}",
"real": "app=core&module=members&controller=profile"
},
"edit_profile": {
"friendly": "profile/{#id}-{?}/edit",
"real": "app=core&module=members&controller=profile&do=edit"
},
…Тогда edit_profile не будет использоваться. profile/1-имя-пользователя URL будет найден первым и вызван диспетчером.
Вместо этого следует сделать так, указав значения следующим образом:
"edit_profile": {
"friendly": "profile/{#id}-{?}/edit",
"real": "app=core&module=members&controller=profile&do=edit"
},
"profile": {
"friendly": "profile/{#id}-{?}",
"real": "app=core&module=members&controller=profile"
},
... это означает что edit_profile будет пропущен, пока не будет определено более частное значение, что позволяет более точно определить все запросы для обработки.