In my autoload file I have several common libraries and several common model autoloaded:
$autoload['libraries'] = array('database','session','tools','common'....);
$autoload['model'] = array('mauth','madmin',...);
I'm in calling this code inside a library that calls another library:
class library1{
function x(){
$this->CI =& get_instance();
$this->CI->library2->y();
}
}
class library2()
function y(){
$this->CI =& get_instance();
$array_notifications = $this->CI->madmin->getNotifications();
}
}
And I get:
Message: Undefined property: Splash::$madmin
I guess I may do this:
$this->CI->load->model('madmin');
But.. why? Why Can't I decide the load priority of my autoloaded classes?
Thanks
EDIT: Clarification
AFAIK there's no possibility of choosing the loading priority, and I think that hacking the core just to avoid writing a line is a bit...off.
I had to go search the core system to see better how things work. Looks like libraries are autoloaded before models, so you are right when saying that you need to load the model before calling one of its methods (I didn't tested though, but I think it works like this).
I don't know why is this done, but so far the only solution I see is to change yourself the order in which are loaded, but I warn you: I think that if things work this way there's a reason the CI developers has thought about; this might have drawbacks you cannot tell, so always be ready to a drawback in case you find problems.
This solution is just a bit speculative and not guaranteed, I'll appreciate your feedback as I cannot set up a testing environment right now to prove it
Go to the system/core/loader.php file, around line 1166 (the method is _ci_autoloader()) where the "libraries" index of $autoload array is checked, and swap its position with the 'model' index checking which is around line 1183.
And good luck :)
I personally think you should avoid autoloading as much as possible, since all resources will remain loaded whether you use them or not, as said here.
Also, be aware that Model autoloading works somewhat differently than autoloading for other objects.
When working with models, CI assumes that any loaded library is also available within the model. So loading libraries before models is actually the right thing to do.
Related
I'm using php and codeigniter, It has autoload class.
My first question is,
If I use autoload class to load all model will it make my application slower? Or is there no effect?
My second question :
Which one is better and faster, loading all model you need using autoload class, Or load only some models you need in a class function?
1) Autoload class will obviously make your application slower. because it uses php4 require function to load files. there are some hacks to use php 5 autoloading feature. Hope, new owner of codeigniter will add add support for autoloading.
2) It is best to use load specific models rather than autoload. in previous point I stated the reason behind this. basically it is good practice to load only the needed model, helper, library and assets. it assures that you use minimum time and memory.
I use autoload. and its working like a charm with no significant impact on loading time.
Method
Add this peace of Code on top of any libraries/models that you use in you CI autoload.php
example for me my config/autoload.php looks like
$autoload['libraries'] = array('database','door','acl','form_validation','notify');
and in libraries/Door.php i added
<?php//libraries/Door.php
function multi_auto_require($class) {
#var_dump("requesting $class");
if(stripos($class, 'CI') === FALSE && stripos($class, 'PEAR') === FALSE) {
foreach (array('objects','core') as $folder){//array of folders to look inside
if (is_file(APPPATH."{$folder}/{$class}.php")){
include_once APPPATH."{$folder}/{$class}.php";
}
}
}
}
spl_autoload_register('multi_auto_require');
class Door {
i added this snippet just above class Door{ in this way this snippet will run on every time codeigniter loads door library.
Testing and benchmarking
now For benchmarking i tested this code in a page with 17 DB queries from 8 Autoloaded Objects from 2 different folder with array of 3 folders to look in.
Result
using above mentioned method Vs include_once 'classlocation.php' for all project classes,
the average of 10 page refreshs for both methods where around 0.6sec;
so you can see there is no significant difference between both methods.
yet although i didn't test it on pages that doesn't use all class's, yet im sure autoloading makes my CI life much better and i'm happy with it.
I'd like to get the names of all classes within a specific namespace in PHP. Currently, I'm attempting to do some magic via reflection on a specific list of named classes, but I'd like to do it without knowing the names ahead of time.
I've tried calling get_declared_classes(), but for whatever reason, classes that I do have available are not showing up. I can call get_declared_classes(), not see Event in the list, then immediately call $x = new Event() without a problem. Something like the following, which I would think should cause a problem...
if (! in_array('Event', get_declared_classes())) { $x = new Event(); }
...works fine. I'm wondering if namespacing these classes and retrieving that way would help alleviate the problem. Is this possible?
EDIT: For clarification, let me add that I am not currently using namespaces, and I am not specifically trying to achieve something from the above listed code. What I want is to get the names of all classes I have declared. Despite the fact the class declarations for all of them are being hit before I call get_declared_classes(), they are not all appearing in the list. I was hoping that namespacing might help solve the problem.
EDIT2: Several people have pointed out that the classes may be autoloaded. I tested this by doing the following. echo(class_exists('Event')) returned a value of 1. echo(class_exists('Event', FALSE)) returned a value of 0. The second, optional parameter to class_exists is whether or not to autoload. So, apparently the class is being autoloaded. That answers that.
So, next question - how do I prevent this? I'm using a framework that really doesn't give me much low-level control. Is there a way to force autoloading, THEN call get_declared_classes, or for get_declared_classes to fire an autoload first?
You do not need to hard code it in the code, you can use variable name:
$class_name = 'Event';
if (!in_array($class_name, get_declared_classes())) {
$x = new $class_name();
};
See similar code in action here: codepad.org/hCLE4ToA.
Also some classes may not appear in get_declared_classes()'s result, because they may not be loaded at the time this function is called. It may be the case if they are autoloaded after you try to instantiate them. See more on autoloading classes here: php.net/autoload.
Does it answer some of your questions? Did it help?
Hello and thanks for reading.
I'll get straight to the point: I have a website project that I've been building using CodeIgniter 1.7.3, which I have thoroughly enjoyed using, however I have been contemplating upgrading to CI 2.0+.
I tried a straight copy, just moved my folders for controllers, models and views over to a CI 2.0 framework, but I got a 500 server error when I tried to view my pages.
After doing some investigation I discovered that all of your controllers must now use "CI_Controller" as their parent class. Also I noticed that if you want to include a constructor in your controller class that it must use the syntax "function __construct()" as its name and of the parent class. It seems that CI 2.0+ no longer supports using a constructor that has the same name as the class name, e.g. "class Blogs extends CI_controller{ function Blogs(){parent::__construct();}}" is no longer supported?
I've been reading the CI Change Log, but all I see are bug fixes, and new features, nothing about compatibility issues with older versions of CI?
Does anyone else know of any other secret little pitfalls?
Thanks,
H
CI 2.x removed all compatibility with PHP4 and also updated a number of standards to be compliant with PHP 5.3 going forward. One of these is the constructor issue you have encountered. As of PHP 5.3, the function ClassName() is no longer the constructor for a class, it is simply another function. You must explicitly declare a __construct function to perform any tasks that need to be done when a new instance of the class is created. Given this, you should see it no longer makes sense to call parent::ClassName() in your child constructor as that function would no longer be the parent's constructor.
Another pitfall I recently had to work out is how the $_GET array is now handled. In the 1.x versions, you could use query strings to pass back extra information and still use URI segments to route to controllers and functions. This is especially useful for AJAX calls where you may not always know all the parameters being sent to and from the server in a particular request. In the 2.x versions, the config.php file contains a new option, $config['allow_get_array']. This must be set to TRUE if you want to use query strings otherwise the input class clears out the $_GET array as part of CI's initialization routine on each request.
Something which isn't a pitfall but you may find useful is the new options in config/autoload.php that allows you to add new application directories to your project. If you work on a number of different projects with CI and want to keep any useful libraries you write in a single location, you can now add that location to $autoload['packages']. CI expects any path in this array to contain the sub-directories "controllers", "models", "libraries" and "helpers". It won't complain if you don't have those directories but you will at least need them for anything you intend to load, i.e. libraries would live in /libraries as with the main application folder.
Have you read the official guide for upgrading from 1.7.x to 2.x ?
so in short
Update Models and Controllers to
extend CI_Model and CI_Controller
Update Parent Constructor calls
class Wow extends CI_Controller {
function __construct()
{
parent::__construct();
//your stuff
}
function index()
{
// just for example
}
}
In Codeigniter, when we use $this->load('class_name') in the controller, CI will try to create an instance of the class/model using its constructor.
But sometimes, I don't actually need an instance from that class, I just want to call some static functions from it. Also, there is a big limitation with $this->load('class_name'), it does not allow me to pass parameters to the constructor (unless we extend or modify the core class of CI).
I think the $this->load('class_name') function should only do a require_once on the class php file for me, and let me freely do things (create instance/call static functions) with the class in the controller.
Should I simply ignore this function and use require_once or writing my own __autoload function to load up the classes? This way, I just feel strange because it seems I am not writing codes inside the CI box.
You can pass parameters to your constructor. See the "Passing Parameters When Initializing Your Class" section in the user guide.
I found CodeIgniter's object creation and loading to be very limiting. I want full control over my code, and little magic in the background. I have instead started using Doctrine's Class Loader. It's very lightweight and is essentially SPL autoloading (also a good alternative). You don't need the whole Doctrine shebang with ORM and all that stuff, just the ClassLoader. There's some configuration tinkering to get this right, but it works wonders.
With PHP 5.3 I now have namespaced classes in the Application directory. For instance I created a new class in the Tests directory: Application\Tests\SomeTest.php
That test could look something like this:
namespace Tests;
class SomeTest {
...
}
I would use this class in my code (controllers, views, helpers) by simply using the fully qualified namespace (i.e. $test = new \Tests\SomeTest) or a "use" statement at the top of my code (use \Tests\SomeTest as SomeTest).
In this way I intend to replace all libraries and models with OO namespaced variants. There are many benefits to this: fast autoloading with SPL, full IDE intellisense support for classes/methods (CodeIgniter is really bad for that), your code is more portable to other frameworks or projects.
That said, I still use a lot of the CodeIgniter engine. This basically means I have $CI =& get_instance() in most of my classes. It's still a work in progress and I think the main reason I need CI is for it's database access. If I can factor that out ... and use something like Dependency Injection, then I won't need CodeIgniter in my classes at all. I will simply be using it for it's MVC framework, and using it's methods occasionally in my controllers.
I know this goes above and beyond your question, but hopefully it's some food for though - and it helps me to get it in writing too.
PHP's __autoload() (documentation) is pretty interesting to me. Here's how it works:
You try to use a class, like new Toast_Mitten()(footnote1)
The class hasn't been loaded into memory. PHP pulls back its fist to sock you with an error.
It pauses. "Wait," it says. "There's an __autoload() function defined." It runs it.
In that function, you have somehow mapped the string Toast_Mitten to classes/toast_mitten.php and told it to require that file. It does.
Now the class is in memory and your program keeps running.
Memory benefit: you only load the classes you need. Terseness benefit: you can stop including so many files everywhere and just include your autoloader.
Things get particularly interesting if
1) Your __autoload() has an automatic way of determining the file path and name from the class name. For instance, maybe all your classes are in classes/ and Toast_Mitten will be in classes/toast_mitten.php. Or maybe you name classes like Animal_Mammal_Weasel, which will be in classes/animal/mammal/animal_mammal_weasel.php.
2) You use a factory method to get instances of your class.
$Mitten = Mitten::factory('toast');
The Mitten::factory method can say to itself, "let's see, do I have a subclass called Toast_Mitten()? If so, I'll return that; if not, I'll just return a generic instance of myself - a standard mitten. Oh, look! __autoload() tells me there is a special class for toast. OK, here's an instance!"
Therefore, you can start out using a generic mitten throughout your code, and when the day comes that you need special behavior for toast, you just create that class and bam! - your code is using it.
My question is twofold:
(Fact) Do other languages have similar constructs? I see that Ruby has an autoload, but it seems that you have to specify in a given script which classes you expect to use it on.
(Opinion) Is this too magical? If your favorite language doesn't do this, do you think, "hey nifty, we should have that" or "man I'm glad Language X isn't that sloppy?"
1 My apologies to non-native English speakers. This is a small joke. There is no such thing as a "toast mitten," as far as I know. If there were, it would be a mitten for picking up hot toast. Perhaps you have toast mittens in your own country?
Both Ruby and PHP get it from AUTOLOAD in Perl.
http://perldoc.perl.org/perltoot.html#AUTOLOAD:-Proxy-Methods
http://perldoc.perl.org/AutoLoader.html
Note that the AutoLoader module is a set of helpers for common tasks using the AUTOLOAD functionality.
Do not use __autoload(). It's a global thing so, by definition, it's somewhat evil. Instead, use spl_autoload_register() to register yet another autoloader to your system. This allows you to use several autoloaders, what is pretty common practice.
Respect existing conventions. Every part of namespaced class name is a directory, so new MyProject\IO\FileReader(); should be in MyProject/IO/FileReader.php file.
Magic is evil!
The Mitten::factory method can say to itself, "let's see, do I have a subclass called Toast_Mitten()? If so, I'll return that; if not, I'll just return a generic instance of myself - a standard mitten. Oh, look! __autoload() tells me there is a special class for toast. OK, here's an instance!"
Rather such tricky code, use simple and verbose one:
try {
$mitten = new ToastMitten();
// or $mitten = Mitten::factory('toast');
} catch (ClassNotFoundException $cnfe) {
$mitten = new BaseMitten();
}
I think this feature comes in very handy, and I have not seen any features like it else where. Nor have I needed these features else where.
Java has something similar. It's called a ClassLoader. Probably other languages too, but they stick with some default implementation.
And, while we're at this. It would have been nice if __autoload loaded any type of symbols, not just classes: constants, functions and classes.
See Ruby's Module#const_missing
I just learned this: Ruby has a method on Module called const_missing that gets called if you call Foo::Bar and Bar isn't in memory yet (although I suppose that Foo has to be in memory).
This example in ruby-doc.org shows a way to use that to implement an autoloader for that module. This is in fact what Rails uses to load new ActiveRecord model classes, according to "Eloquent Ruby" by Russ Olsen (Chapter 21, "Use method_missing for flexible error handling", which also covers const_missing).
It's able to do this because of the "convention over configuration" mindset: if you reference a model called ToastMitten, if it exists, it will be in app/models/toast_mitten.rb. If you could put that model any place you wanted, Rails wouldn't know where to look for it. Even if you're not using Rails, this example, and point #1 in my question, shows how useful it can be to follow conventions, even if you create them yourself.