I have a site which uses an index.php as a controller, and a couple of view pages (such as search.php and form.php) which are both ‘included’ via the index.php. So my question is, if I have an object instantiated in index.php is it in operation in any number of pages, provided they are all included from the index.php file that created the object.
A simple question, perhaps, but one which I really would like to be sure of the answer.
I must say, I like using an index file and then ‘including’ other files, a technique which I learned while reading Kevin Yank’s books.
Well, this would be a case of “there’s the rule, and then there’s all the exceptions.”
An object by default would only be in existence during a single execution. (Read: Until you get to the final line of index.php, in this example). Garbage collection then cleans everything up.
HOWEVER;
An object instantiated into the $_SESSION global array would (provided index.php invoked session_start() ) exist for the duration of the session.
An object passed as a cookie (bad idea, but possible) would persist for the lifetime of the cookie. (Actually it wouldnt - it’d get passed back and forth repeatedly, with the object’s server-local existence being destroyed by garbage cleanup as usual)
Including is treated (for the most part) as though you took the contents of the included file, and inserted them at that point. Variables are in-scope, functions, etc. (The reverse is also true, if the included page defines variables or functions, they are available in the global scope of the file that did the including.)
Well as far as I know, the object is available for the lifetime of the HTTP request, although for temporary objects created in methods they will not be accessible after method call completes. You can manually destroy the object by unsetting it, I seldom do this myself though. If you are simply including files, objects included in these files should be available to you during the current HTTP request. Be aware that including files with global data is not a good practice, you should only include class or function source files instead. Many IDEs wont even be able to recognize variables/objects defined in an included file, a good example is Netbeans, but it helps since I end up refactoring my application so that no variable is loaded by including files.
Alternatively you can store an object in a session so it will be available throughout a user session, which ends with the user closing the browser or manually destroyed by the internal script. This way the object will be active even after you refresh the page, but since PHP session vars cannot store objects you have to play the serialize/unserialize trick all the time. Sessions can be useful, but over-relying on session is also a poor programming practice. A session var exists only if it must exist, so use this feature sparingly. For cookies, I only use it to store user login info such as user id and username, its not safe so do not even use it for password.
There’s nothing wrong with storing an object in a session. The exception to this is storing a resource in an object, you can’t for example store a db connection in an object and pass that object to the next request, not that you’d want to)
According to the docs, classes’ destruct class is called when it is no longer used, but usually winds up being until end of execution (test by playing with the magic __destruct() function.
Thanks for that. At least now I know the direction my searching and learning must go in. I can find out how to instantiate an object into the $_SESSION array. I didn’t know you could do that, but then I should have known, it seems you can do most anything with PHP.