Как расширить класс контроллера воспламенителя кода?

В моем каталоге CI system \ libraries у меня есть новый класс с именем DD_Controller.php. Этот файл выглядит следующим образом:

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed'); class DD_Controller extends Controller { protected $ddauthentication; function __construct() { parent::Controller(); $this->ddauthentication = "Authenticated"; } } ?> 

Мой контроллер приложений определяется следующим образом:

 class Inquiry extends DD_Controller {...} 

Класс «Запрос» отлично работает, когда я расширяю контроллер, но я получаю

Неустранимая ошибка: класс «DD_Controller» не найден в C: \ development \ localhost \ applications \ query \ controllers \ request.php в строке 4

Когда я расширяю DD_Controller. В конфигурационном файле у меня есть префикс, определенный как таковой:

 $config['subclass_prefix'] = 'DD_'; 

Любая идея о том, что мне не хватает?

ТИА

DD_Controller.php должен быть в / system / application / libraries /

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

В системе / library / Controller.php ниже класса Controller:

 class Mega_Controller extends Controller { function Mega_Controller() { parent::Controller(); // anything you want to do in every controller, ye shall perform here. } } 

Тогда вы сможете это сделать в своих контроллерах приложений:

 class Home extends Mega_Controller { .... 

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

Это лучший подход. Выполните следующие действия:

  1. Перейдите в следующий каталог: your_ci_app/application/core/ и создайте php-файл с именем MY_Controller.php (этот файл будет содержать ваши MY_Controller.php родительские классы)
  2. Откройте этот файл, который вы только что создали, и добавьте несколько классов, например:

     class Admin_Parent extends CI_Controller { public function __construct() { parent::__construct(); } public function test() { var_dump("from Admin_Parent"); } } class User_Parent extends CI_Controller { public function __construct() { parent::__construct(); } public function test(){ var_dump("from User_Parent"); } } 
  3. Создайте дочерние контроллеры в этом каталоге your_ci_app/application/controllers/ . Я назову его adminchild.php

  4. Откройте adminchild.php и создайте свой код контроллера, убедитесь, что расширили имя родительского класса, например:

     class Adminchild extends Admin_Parent { function __construct() { parent::__construct(); } function test() { parent::test(); } } 

Я рекомендую избегать «взлома» основных файлов CodeIgniter. Лучше используйте свои возможности расширения и попытайтесь вписаться в них.

То же правило, которое я бы рекомендовал для любой библиотеки PHP / CMS. У этого правила есть несколько причин: – способность к quiklky обновить без takint во внимание тысячи заметок, где и как был взломан в основных файлах; – переносимость; – возможность поделиться своим кодом – например, это будет полезно вам и вашим друзьям в случае необходимости, и это поможет им обновить свою библиотеку так же, как и вы.

Другими словами, это гораздо более профессионально, и в будущем он платит вам за удобство использования, переносимость и возможность применения обновлений.

Что касается вашего личного вопроса …

Что касается меня, нет ничего плохого в создании собственной библиотеки со всем необходимым для расширения собственного CodeIgniter Controller, а затем загрузите эту библиотеку в конструктор контроллера, и все готово. Единственное, что можно улучшить, – это короткое имя вашей библиотеки.

Таким образом, вы даже можете разделить то, что вам нужно, на разные части и поместить в отдельные библиотеки: WebFeatures AdminFeatures и т. Д.

Затем вы просто загружаете необходимые библиотеки в конструктор вашего контроллера, и все готово.

PS Я знаю, что предложенный способ не вписывается в «правильную» концепцию ООП, но в то же время вы никогда не должны забывать о целостности используемых библиотек.

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

Привет, Антон