Modular Extensions - HMVC version 5.3

[eluser]wiredesignz[/eluser]
@newkiwi, Thanks for that.

Remember too, that in ordinary CI code, the controller is the core, so any variables that are assigned to the controller may oveload the core class variables and cause the same problem.

Modular Extensions controllers refer to a separate core CI class (object), so in effect assigning variables to $CI is doing exactly the same thing.

[eluser]Philipp Gérard[/eluser]
I always get "Fatal error: Class 'MX_Config' not found in /home/zeitdenken/domains/entwicklung.zeitdenken.eu/public/application/third_party/MX/Base.php on line 74" when using a fresh checkout from CI2 and your source (using app/core & app/3rdp). I have no clue why everybody except me seems to get this running. Working with PHP 5.3.2 on a LAMP. Any hints?

[eluser]wiredesignz[/eluser]
@Philipp Gérard, follow this link.
http://ellislab.com/forums/viewreply/796799/

[eluser]ardinotow[/eluser]
[quote author="ardinotow" date="1285064964"]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[/quote]
[quote author="wiredesignz" date="1285073574"]@ardinotow, follow this link.
http://ellislab.com/forums/viewreply/796799/[/quote]

Still no luck. Now I'm getting this error Fatal error: Class 'MX_Config' not found in /home/ardinoto/workspace/jobica/application/third_party/MX/Ci.php on line 51. Because I don't want to use HMVC features, MY_Controller.php is not copied on to libraries folder.

Btw, my problem maybe the same as Philipp Gérard's but I use CI 1.7.2
Please help...thanks

[eluser]wiredesignz[/eluser]
Yes correct, do not use MY_Controller.php for Modular Separation only. However you still require application/libraries/MY_Loader.php and application/libraries/MY_Router.php if using CI 1.7

If you also use MY_Language.php and/or MY_Config.php you must include (require) the corresponding MX/Lang.php and MX/Config.php files

[eluser]ardinotow[/eluser]
[quote author="wiredesignz" date="1285144148"]
If you also use MY_Language.php and/or MY_Config.php you must include (require) the corresponding MX/Lang.php and MX/Config.php files[/quote]
Yes, solved! Thank you so much !!

[eluser]Philipp Gérard[/eluser]
I wanted to use the full package but no luck so far. I compared the wiki to your latest bitbucked-release of the howto, but saw no major difference in the installation process.

[eluser]Phil Sturgeon[/eluser]
I updated the CI wiki to contain the same details as wiredesignz BitBucket instructions, as that is the first place people will look.

What errors are you getting? "no luck so far" is a bit vague. :lol:

[eluser]Phil Sturgeon[/eluser]
[quote author="newkiwi" date="1285083698"]@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.[/quote]

I finally found the time to play with this one and got my CMS (not Pyro) converted nicely.

I've added a __get to MY_Controller that will check the CI super-global

Code:

require APPPATH.'third_party/MX/Controller'.EXT;

class MY_Controller extends MX_Controller
{
    protected $data;

    function __construct()
    {
            // Set super-global properties like this
            ci()->site = $this->sites_m->get_by('domain', $this->input->server('SERVER_NAME');

            // Reffer to them in your controllers, libraries and models like this:
            echo $this->site->id;
        }

    function __get($var)
    {
        if(isset(ci()->$var))
        {
            return ci()->$var;
        }

        // Maybe its in the HMVC instance
        parent::__get($var);
    }
}

/**
* Returns the CI object.
*
* Example: ci()->db->get('table');
*
* @staticvar    object    $ci
* @return        object
*/
function ci()
{
    static $ci;
    isset($ci) OR $ci =& get_instance();
    return $ci;
}

Works perfectly and doesnt need me to change any code in my controllers, models or libraries. Whoop!

[eluser]wiredesignz[/eluser]
I do like the parent::__get($var) EDIT: I just noticed it needs a return

However I tend to use a reference to the loader _ci_cached_vars array as a variable store. This allows all values to also be available to views by default and is a nice common place to store data.

Code:

$this->data =& $this->load->_ci_cached_vars;

Now any changes to $this->data are actually changes to the loader cached vars and shared by views, all HMVC controllers and the CI core