Welcome Guest, Not a member yet? Register   Sign In
Clarification about MY_Controller and relative inheritances
#11

(04-17-2017, 04:37 PM)dave friend Wrote: But, if MY_Controller does not mess with any CI_Controller properties (and it only has one - private static $instance; so there is nothing to mess with) then technically he does not need to explicitly call the base class constructor. PHP will do it anyway.

That is true, but in that case the MY_Controller class may not have a __construct() method. If it does have a __construct() method you MUST call the parent::_construct manually.

So the question is:
Does @gbwebapps have an empty constructor in his MY_Controller class?
Reply
#12

(04-17-2017, 08:53 PM)marksman Wrote: If that the case then would you think how CI include the file of backend/frontend controller without modifying config.php from MY_ convention to your own or by creating your own autoloader inside MY_Controller

I'm not sure I understand the above statement. I think you're asking, "How do you include individual child class files without using $config['subclass_prefix'] or an autoloader?" If that's what your asking then you're left with using "include" or "require" to manually load the files i.e.
PHP Code:
include_once(APPPATH.'libraries/Backend_Controller.php'); 
   

One of Avenir's tutorials shows multiple ways to handle extending CI_Controller multiple times or even how to create multiple "base" controllers.

My preference is an autoload function inside a hook. That approach means you can use "the codeigniter way" when loading classes and maintain the best practice of one class per file. It also means you can abandon the use of $config['subclass_prefix'] all together and put all your child class files (including any that subclass CI_Controller) in the application/libraries/ folder.

I often find the need to subclass custom libraries that are not children of CI_Controller. But because of its design CI cannot load a subclass of a custom library - it can't find the parent file. That means either resorting to include/require or an autoloader.
Reply
#13

(This post was last modified: 04-18-2017, 04:32 PM by marksman.)

(04-18-2017, 07:10 AM)dave friend Wrote:
(04-17-2017, 08:53 PM)marksman Wrote: If that the case then would you think how CI include the file of backend/frontend controller without modifying config.php from MY_ convention to your own or by creating your own autoloader inside MY_Controller

I'm not sure I understand the above statement. I think you're asking, "How do you include individual child class files without using $config['subclass_prefix'] or an autoloader?" If that's what your asking then you're left with using "include" or "require" to manually load the files i.e.
PHP Code:
include_once(APPPATH.'libraries/Backend_Controller.php'); 
   

One of Avenir's tutorials shows multiple ways to handle extending CI_Controller multiple times or even how to create multiple "base" controllers.

My preference is an autoload function inside a hook. That approach means you can use "the codeigniter way" when loading classes and maintain the best practice of one class per file. It also means you can abandon the use of $config['subclass_prefix'] all together and put all your child class files (including any that subclass CI_Controller) in the application/libraries/ folder.

I often find the need to subclass custom libraries that are not children of CI_Controller. But because of its design CI cannot load a subclass of a custom library - it can't find the parent file. That means either resorting to include/require or an autoloader.

It will do the job, but I don't think it's the best practice. That's why there's a function called spl_autoload_register to do the job inside it Smile

PS: Or simply use the framework's convention to autoload your files. Smile
God Bless CI Contributors Smile
Reply
#14

(04-18-2017, 04:31 PM)marksman Wrote: It will do the job, but I don't think it's the best practice.

Once again I do not understand the above statement. The pronoun's antecedent is vague in the extreme. To put that more clearly, what the heck is the "it" you're talking about?

marksman Wrote:Or simply use the framework's convention to autoload your files.
As I pointed out, the framework's "convention to autoload" design is not always adequate. For instance, consider two custom libraries.

File: application/libraries/CustomLib1.php
PHP Code:
class CustomLib1
{
 
   ...


And a second class that extends CustomLib1

File: application/libraries/CustomLib2.php
PHP Code:
class CustomLib2 extends CustomLib1
{
 public function 
__construct()
 {
 
       parent::__construct();
 }


If you're relying on the framework's "convention to autoload" and make the following call
PHP Code:
$this->load->library('CustomLib2'); 

You will receive a fatal error stating that Class 'CustomLib1' cannot be found.
To overcome this problem you have a couple options.

First option: Manually include the base class file before trying to load the child class.
PHP Code:
include APPPATH 'libraries/CustomLib1.php';
$this->load->library('CustomLib2'); 

Second option: Implement an autoloader.

The second option is what I prefer.

I'm happy to hear that you know spl_autoload_register is used to implement an autoloader. Big Grin
Reply
#15

(04-18-2017, 01:57 AM)Martin7483 Wrote:
(04-17-2017, 04:37 PM)dave friend Wrote: But, if MY_Controller does not mess with any CI_Controller properties (and it only has one - private static $instance; so there is nothing to mess with) then technically he does not need to explicitly call the base class constructor. PHP will do it anyway.

That is true, but in that case the MY_Controller class may not have a __construct() method. If it does have a __construct() method you MUST call the parent::_construct manually.

So the question is:
Does @gbwebapps have an empty constructor in his MY_Controller class?

The point I failed to make is that however he has defined MY_Controller it must be OK. If it was not then his call to $this->load->model('Auth_Model'); in Dashboard::index() would produce the error: "Undefined property: Dashboard::$load".

But he says it works. If Dashboard has access to $load then CI_Controller::__construct() did execute.

Still, it would be nice to see the code for MY_Controller and to see the error message he mentions.
Reply
#16

(This post was last modified: 04-19-2017, 04:54 PM by marksman.)

(04-19-2017, 06:58 AM)dave friend Wrote:
(04-18-2017, 04:31 PM)marksman Wrote: It will do the job, but I don't think it's the best practice.

Once again I do not understand the above statement. The pronoun's antecedent is vague in the extreme. To put that more clearly, what the heck is the "it" you're talking about?

marksman Wrote:Or simply use the framework's convention to autoload your files.
As I pointed out, the framework's "convention to autoload" design is not always adequate. For instance, consider two custom libraries.

File: application/libraries/CustomLib1.php
PHP Code:
class CustomLib1
{
 
   ...


And a second class that extends CustomLib1

File: application/libraries/CustomLib2.php
PHP Code:
class CustomLib2 extends CustomLib1
{
 public function 
__construct()
 {
 
       parent::__construct();
 }


If you're relying on the framework's "convention to autoload" and make the following call
PHP Code:
$this->load->library('CustomLib2'); 

You will receive a fatal error stating that Class 'CustomLib1' cannot be found.
To overcome this problem you have a couple options.

First option: Manually include the base class file before trying to load the child class.
PHP Code:
include APPPATH 'libraries/CustomLib1.php';
$this->load->library('CustomLib2'); 

Second option: Implement an autoloader.

The second option is what I prefer.

I'm happy to hear that you know spl_autoload_register is used to implement an autoloader.  Big Grin

Maybe you have poor understanding.

I'm talking about your post, It's about including file manually,

If using framework's convention in your case is not applicable then create your own convention on top of framework's convention.

I don't have much time to explain it and argue with you.

Quote:I just want to say that your way will work but IF you will be working with someone else (with a team, big projects, real world) your way will be rejected in code review phase of your project for sure Smile

No offense but just saying the reality. If you still want your way then do it your way Smile

its your choice if you want to keep it wrong or just do the best practices.
God Bless CI Contributors Smile
Reply




Theme © iAndrew 2016 - Forum software by © MyBB