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"; In a test library, e.g. App.php in \libraries Code: class App In Welcome controller (modules\welcome\controllers) Code: class Welcome extends User_Controller { 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); 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]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. |
Welcome Guest, Not a member yet? Register Sign In |