Modular Extensions - HMVC version 5.3

[eluser]wiredesignz[/eluser]
@maltzurra, autoloading config arrays works properly. Check the config array in your base controller.

Code:

print_r($this->config);

@newkiwi, Any class variable defined in a parent class is available in the extended classes. This is basic PHP and has nothing to do with Modular Extensions - HMVC or CodeIgniter.

Note: the CI class 'instance' method is deprecated in version 5.3

[eluser]newkiwi[/eluser]
Hi bryantAXS

All I did was to have a library (e.g. called App) in \libraries) and move all global vars and initialization into that library class.


I load this library up in the constructor to MY_Controller or other base controllers.

From there, I just access this using the $this->ci->app-> reference (from other libraries) and $this->app-> from any controller or Extended controller.

The advantage of this is
(1)on instantiating the library we can trigger auto init routines via that library's constructor.

(2) that we can place common display routines, e.g. get flash messages and sidebar viewes etc in this common library.

This is vaguely similar to an approach in e.g. VB6 or .Net where we call a startup core 'application' class that calls other forms, starts up DB etc etc

I foun this better than the $CI::->data = & $this->data approach.
And more disciplined.

But it is a bit more effort than just sticking global app vars in the base Controller

[eluser]newkiwi[/eluser]
@wiredesignz

I just tested with a clean HMVC/CI 2.0.

The problem is not when Controllers try to access data/var of their parent Controllers - as per normal PHP class heirachy that works,
but when libraries called by a downsteam controller cannot access the public data/vars of the parent Controller
via the normal $this->ci->[data/varname] construct within the library.

i.e. in normal CI, the Controller data can be accessed via the CI instance from any library

E.g. my test code

In core\MY_Controller

Code:

require APPPATH."third_party/MX/Controller.php";

class MY_Controller extends MX_Controller
{
    var $data = 'test';//TEST PUBLIC VAR
    
    function __construct()
    {
        parent::__construct();
        $this->load->library('app');
    }
    
    function test()
    {
        echo $this->data;//WORKS
    }
    
}


class User_Controller extends MY_Controller
{
    function __construct()
    {
        parent::__construct();
    }
    
    function childtest()
    {
        echo $this->data; //WORKS
    }

}

In a test library, e.g. App.php in \libraries

Code:

class App
{
    function __construct()
    {
        $this->ci =& get_instance();
    }

    function testit()
    {
        echo $this->ci->data;//FAILS
    }

}

In Welcome controller (modules\welcome\controllers)

Code:

class Welcome extends User_Controller {

    function __construct() {
        parent::__construct();
    }

    /*
     * default method
     */
    
    function index()
    {
        echo $this->data; //WORKS
        
        $this->app->testit();//FAILS
        /*Message: Undefined property: CI::$data

        Filename: libraries/app.php

        Line Number: 12
        */
        
        $this->load->view('welcome_message');
    }
}

Here the app library referencing the MY_Controller $data var fails

Code:

$this->ci->data;//FAILS

Have I missed something?

[eluser]wiredesignz[/eluser]
You are making the library dependent on the controller which is not good practice. Pass the variable in to the library.
But if you must use the CI instance then assign your variable to it rather than the controller. It will be available to all controllers by default.

[eluser]ardinotow[/eluser]
Hai wire,
I try the simple one to test modular system by creating welcome modules as shown on wiki page, but I got Fatal error: Class 'MX_Config' not found in /home/ardinoto/workspace/jobica/application/third_party/MX/Base.php on line 74.

What went wrong ? Seems like no one in this discussion had this problem.
Thanks

[eluser]wiredesignz[/eluser]
@ardinotow, follow this link.
http://ellislab.com/forums/viewreply/796799/

[eluser]maltzurra[/eluser]
[quote author="wiredesignz" date="1285035300"]@maltzurra, autoloading config arrays works properly. Check the config array in your base controller.

Code:

print_r($this->config);

[/quote]

My bad. I was modifying Phil's PyroCMS for testing purposes and it wasn't working as expected.

The problem was on the hook itself. It was on:

Code:

require_once(APPPATH.'config/language.php');

As the language.php config file was being autoloaded, require_once didn't get $config values, and it was generating an error. Noobish error

Just my 2 cents. Let's stay on topic.

[eluser]Phil Sturgeon[/eluser]
newkiwi: I've found the exact same problem and not yet found a good way to get around. When I do (need to find time to actually do it) I will let you know. You won't get any answer from wiredesignz other than "its bad practice" which is entirely unproductive.

[eluser]wiredesignz[/eluser]
@phil, I said pass the value in to your library. Or if you must, attach the variable to the $CI instance rather than the controller. Which part of that is too difficult for you to understand buddy?

[eluser]newkiwi[/eluser]
@phil
@wiredesignz

thanks for the feedback, guys. I appreciate both your viewpoints.

From a puristic coding/architecture point wiredesignz's view has validity. I have had issues where the Controller vars "leak" and get confused with CI vars/objects where they share names!!! and hence wiredesignz more disciplined approach would have prevented that.

The idea of explicitly linking all vars to the CI instance directly or via a library of course works. The core 'app data' library idea - which I use has strengths in the discipline it imposes of explicitly marshalling all the global vars/inits in one place.

The idea of creating all global vars in controllers via the CI instance

Code:

$this->ci->VAR = VALUE;

is probably the simplest recommendation for newbies using HMVC - unless it clashes with library and class object names!!!.

Of course its just easier/lazy and maybe messy to add the vars to base controllers - prob a common practice we all fall into.