Статьи

Как работает система крюков CodeIgniter

Как разработчик CodeIgniter, иногда вы попадаете в ситуацию, которая требует, чтобы вы изменили ядро ​​платформы или поток выполнения, чтобы выполнить ваши пользовательские требования. Конечно, никогда не рекомендуется изменять основные файлы, поскольку это делает процесс обновления громоздким. К счастью, платформа CodeIgniter поставляется с системой ловушек, которая позволяет вам справиться с этим сценарием.

В этой статье мы начнем с введения в систему хуков в среде CodeIgniter. Затем мы обсудим различные типы доступных крючков. И, наконец, мы воспользуемся этой возможностью, чтобы изучить создание пользовательских хуков.

Давайте кратко рассмотрим, что говорится в официальной документации CodeIgniter о системе хуков:

Функция хуков CodeIgniter предоставляет средства для доступа и изменения внутренней работы фреймворка без взлома основных файлов.

Звучит довольно понятно, не так ли? В вашей повседневной разработке приложений, если вы когда-нибудь испытываете желание изменить основные файлы CodeIgniter, вы должны сначала рассмотреть систему хуков, чтобы проверить, отвечает ли она вашим требованиям.

Предположим, что вы хотите создать собственную систему оценки производительности, чтобы отслеживать выполнение приложения. Вы понимаете, что файлы ядра должны быть изменены для достижения желаемого результата. В этом случае вы можете использовать pre_system и post_system чтобы войти в поток выполнения и собрать статистику по мере необходимости.

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

Это было базовое введение в систему хуков в CodeIgniter. В следующем разделе мы подробно рассмотрим различные хуки, доступные для подключения к системе.

Система подключений CodeIgniter предоставляет различные точки подключения, которые вы можете использовать при реализации своих пользовательских подключений. Точка подключения — это, по сути, определенное состояние в рабочем процессе выполнения запроса в данный момент времени.

Например, когда вы реализуете pre_system , вы знаете, что находитесь в самом начале фазы начальной загрузки. С другой стороны, если вы выбрали хук post_system , вы можете быть уверены, что выполнение завершено и ответ уже отправлен клиенту.

В этом разделе мы рассмотрим различные точки подключения, которые предоставляются системой подключения CodeIgniter.

pre_system и post_system подпадают под эту категорию, поскольку первая вызывается очень рано на этапе начальной загрузки, а вторая вызывается после завершения выполнения страницы.

Я могу вспомнить несколько вариантов использования, которые могут быть достигнуты с помощью системных хуков:

  • эталонный тест
  • логирование
  • Перенаправление на основе правил
  • И более

Есть три крючка, которые подпадают под эту категорию, поэтому давайте рассмотрим каждый из них.

pre_controller вызывается непосредственно перед созданием класса контроллера. Итак, если вы хотите выполнить какие-либо дальнейшие проверки перед вызовом контроллера, это та ловушка, которую вы ищете.

Как следует из названия, post_controller_constructor вызывается сразу после создания экземпляра объекта контроллера и до фактического вызова метода.

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

post_controller вызывается после выполнения метода контроллера. Поэтому то, что вы хотите выполнить после выполнения контроллера, должно быть реализовано с помощью этого хука.

Так что это была история специфичных для контроллера хуков.

Согласно документации CodeIgniter, хук display_override переопределяет основной метод _display . Основной метод _display используется для отправки вывода клиенту, и, таким образом, с помощью ловушки display_override вы можете изменить способ отправки вывода пользователю.

На самом деле, мы рассмотрим этот хук подробно, когда перейдем к следующему разделу, в котором мы обсудим, как создать свой хук.

cache_override переопределяет основной метод _display_cache класса Output . Метод _display_cache отвечает за обслуживание кэшированных выходных данных, поэтому вы можете использовать эту ловушку, если хотите обслуживать выходные данные страницы из другого кэшированного местоположения на тот случай, если вы внедрили другой механизм кэширования.

На этом история о различных точках подключения в системе подключений CodeIgniter заканчивается. В следующем разделе мы увидим, как именно вы можете воспользоваться преимуществами системы хуков, реализовав пример из реальной жизни.

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

В нашем случае мы будем использовать хук display_override который будет отвечать за замену токена. Чтобы быть более точным, мы заменим все вхождения [DATETIME] на текущую дату. Конечно, это звучит как довольно простой вариант использования, но вы можете легко расширить его, чтобы он был более конкретным в соответствии с вашими требованиями.

По умолчанию система ловушек отключена в базовой структуре, поэтому первое, что вам нужно сделать, это включить систему ловушек.

Идите дальше и откройте файл конфигурации application/config/config.php .

Найдите следующий фрагмент и включите его, изменив FALSE на TRUE .

01
02
03
04
05
06
07
08
09
10
11
<?php
/*
|—————————————————————————
|
|—————————————————————————
|
|
|
|
*/
$config[‘enable_hooks’] = FALSE;

Теперь мы готовы определить наши крючки. На самом деле CodeIgniter уже поставляется с файлом application/config/hooks.php который вы можете использовать, если хотите определить хуки.

По умолчанию файл hooks.php пуст, поэтому давайте добавим наш собственный код ловушки, чтобы сделать его более значимым.

1
2
3
4
5
6
7
8
9
<?php
defined(‘BASEPATH’) OR exit(‘No direct script access allowed’);
 
$hook[‘display_override’] = array(
        ‘class’ => ‘ReplaceToken’,
        ‘function’ => ‘replacePlaceholderCode’,
        ‘filename’ => ‘ReplaceToken.php’,
        ‘filepath’ => ‘hooks’
);

Синтаксис определения пользовательского хука довольно прост. Это массив $hook который содержит все хуки, которые необходимо выполнить.

Ключ каждой записи массива — это имя самого хука, который вы определяете. Когда вы определяете ловушку, вы говорите системе выполнить определенный фрагмент кода, когда что-то происходит. Это именно то, что нужно указать в качестве значения любого хука. Давайте быстро пройдемся по каждому ключу.

  • Ключ class содержит имя класса, который содержит код, который должен быть выполнен.
  • function клавиша содержит имя метода, который будет вызван при выполнении ловушки.
  • Ключ filename указывает на файл, который определяет полный код ловушки.
  • Путь к файлу определяет путь к каталогу файла, объявленного в ключе filename , и он относится к каталогу application . Как правило, он устанавливается для hooks , в результате чего получается структура application/hooks . Конечно, ничто не мешает вам определить совершенно другой путь, если вы хотите это сделать.

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

В нашем случае мы создадим файл ReplaceToken.php и в соответствии с определением хука он должен быть помещен в каталог application/hooks .

Идем дальше и создаем файл application/hooks/ReplaceToken.php со следующим содержимым.

01
02
03
04
05
06
07
08
09
10
11
12
13
14
15
16
17
18
19
<?php
class ReplaceToken {
  public function replacePlaceholderCode()
  {
      // load the instance
      $this->CI =& get_instance();
       
      // get the actual output
      $contents = $this->CI->output->get_output();
       
      // replace the tokens
      $this->CI->load->helper(‘date’);
      $contents = str_replace(«[DATETIME]», standard_date(), $contents);
       
      // set the output
      echo $contents;
      return;
  }
}

Цель нашей ловушки — заменить заполнитель [DATETIME] фактической датой до того, как вывод любой страницы в нашем приложении будет отправлен клиенту.

Как мы уже говорили ранее, вывод страницы уже сформирован к тому времени, когда вызывается хук display_override . Итак, первое, что мы хотели бы сделать, это получить выходные данные, которые готовы к отправке пользователю.

1
2
3
4
5
// load the instance
$this->CI =& get_instance();
 
// get the actual output
$contents = $this->CI->output->get_output();

Метод get_instance используется для создания экземпляра приложения и назначается для $this->CI . Далее мы используем метод get_output класса Output для извлечения содержимого ответа.

Остальное довольно просто. Заполнитель [DATETIME] необходимо заменить фактической датой. Чтобы упростить задачу, помощник по date используется для выполнения желаемой операции, и мы почти закончили с логикой хука.

1
2
3
// replace the tokens
$this->CI->load->helper(‘date’);
$contents = str_replace(«[DATETIME]», standard_date(), $contents);

Наконец, вам нужно _display вывод, так как display_override переопределяет метод _display который используется для отправки вывода клиенту. Таким образом, мы должны сделать это сами в этом случае; в противном случае это было бы обработано основным методом _display .

1
2
3
// set the output
echo $contents;
return;

Фактически, на этом история нашего кастомного крючка заканчивается!

Теперь давайте продолжим и создадим новую страницу CodeIgniter, чтобы мы могли протестировать наш пользовательский хук. Создайте файл application/controllers/TokenExample.php со следующим содержимым.

1
2
3
4
5
6
7
8
9
<?php
defined(‘BASEPATH’) OR exit(‘No direct script access allowed’);
 
class TokenExample extends CI_Controller {
    public function index()
    {
        $this->load->view(‘token_content’);
    }
}

А вот как должен выглядеть связанный файл представления application/views/token_content.php .

1
Today’s date: [DATETIME]

И это в значительной степени так. Укажите в браузере http: // your-code-igniter-site-url / TokenExample / index, и вы увидите ожидаемый результат!

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

Сегодня мы познакомились с одной из замечательных встроенных функций CodeIgniter — хуками. Хуки позволяют вам вмешиваться в типичный рабочий процесс выполнения запросов вашего приложения CodeIgniter.

В начале статьи мы обсудили базовую концепцию хуков в CodeIgniter, а затем обсудили различные хуки, доступные в системе. Наконец, в последнем разделе мы рассмотрели, как создать пользовательский хук и его внутреннюю работу.

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