Чтобы решить эту проблему, важно понять иерархическую природу фреймворка Kohana 3. Когда дело доходит до переопределения или расширения модулей, вам нужно сделать следующее.
Давайте расширим модуль Auth. Когда вы смотрите на структуру файловой системы модуля Auth, вы замечаете, что в каталоге classes
есть файл с именем auth.php
. При открытии этого файла вы видите следующее:
<?php defined('SYSPATH') OR die('No direct access allowed.');
abstract class Auth extends Kohana_Auth { }
Здесь определен абстрактный класс с именем Auth
, который расширяет класс Kohana_Auth
. Когда вы используете ссылки на класс Auth
в своем приложении, вы ссылаетесь на этот абстрактный класс. Фактическая реализация Auth
фактически хранится в классе Kohana_Auth
, который находится в папке Kohana
, которая является частью структуры каталога модуля.
Чтобы расширить модуль Auth
, т. Е. Добавить свои собственные функции, вы просто помещаете файл auth.php
в папку classes
каталога вашего приложения. В своем файле auth.php
вы расширяете свою версию модуля Auth
, расширяя класс Kohana_Auth
. Вот так:
<?php defined('SYSPATH') OR die('No direct access allowed.');
class Auth extends Kohana_Auth {
public function get_user()
{
$result = parent::get_user()
// implement your functionality here.
return $result;
}
public function my_added_functionality()
{
}
}
Из-за иерархической природы каркаса абстрактный класс Auth
, определенный как часть модуля, никогда не будет загружен, потому что каркас сначала загружает ваш класс Auth
, потому что он имеет приоритет. Расширяемый вами класс Kohana_Auth
предоставляет все оригинальные функции, которые вы не можете расширять и / или изменять.
Для получения дополнительной информации о проверке поведения эта часть документации.