Лично я бы расширил библиотеку Controller (создайте MY_Controller, следуя инструкциям внизу Создание библиотек на codeigniter.com ).
Вы бы использовали свою модель и т. Д. Как обычно. Затем вы должны создать частную функцию в вашем классе MY_Controller, чтобы получить соответствующие «глобальные» данные и вызвать
$this->load->vars('everywhere_data', $data_from_relevant_models);
, что сделает данные доступными для всех представлений, вызываемых с этого момента как $everywhere_data
. Затем добавьте ссылку на эту функцию в конструктор MY_Controller, возможно, с условной проверкой фактического входа пользователя в систему.
Если собрать и получить все эти данные сложно, вы можете написать библиотеку для их обработки, но часть 'controller' все равно будет выполнена MY_Controller: то есть, чтобы получить данные и затем использовать load-> vars. () чтобы опубликовать его в виде.
В качестве быстрого и непроверенного примера MY_Controller запустит что-то вроде следующего:
<?php
class MY_Controller extends Controller
{
private $logged_in_user;
function MY_Controller()
{
parent::Controller();
if( $this->_logged_in_userid() > 0 )
{
$this->logged_in_user = $this->_get_user( $this->logged_in_userid() );
$this->load->vars('logged_in_username', $this->logged_in_user->username );
} else {
$this->logged_in_user = false;
}
}
...
}
Обратите внимание, что такие вещи, как _logged_in_userid()
будут иметь доступ к сеансу для вас (например, return $this->session->userdata('logged_in_userid');
), а _get_user()
будет обращаться к соответствующим моделям.
Наконец, у вас будет представление, которое обращается к $logged_in_username
(или everywhere_data
в моем первом примере), которое вы вызываете в свои заголовки и т. Д. Это оставляет ваши обычные контроллеры незагроможденными, чтобы они могли сосредоточиться на предоставлении своей специфической функциональности останавливает переписывание кода несколько раз И поддерживает идеалы MVC.