I have searched and searched and found tons of examples but it seems that everyone has a different opinion about how and when to use session, some use it some say it is evil...
Here is my use case.
I have a Class that has several variables that will need to be used on every page in my application. These variables values are set by making a SOAP call to an API that I am working with. The SOAP call is relatively quick but I am trying to understand how to avoid making a call to the API on every page. I would much prefer to make the call once and then "store" the values somewhere.
I would think that I would just create an Instance of my class on some say Init.php page, make the SOAP calls and then store the whole class in session. Then on all of my pages include the Init.php page. In that page I would do a check to see if the Class existed in the session and if so then pull it form the session.
I know I have to serialize\deserialize the class to do this but I am looking for some feedback here on weather this is the right way to satisfy this use case or if there is a better option?
I am kinda new to PHP, mostly a .NET guys and in .NET the session is generally the best way forward.
All input is appreciated.
thanks
I assume when you stay "serialize\deserialize the class," you really mean you want to serialize/deserialize a class instance (an object) in the session, not the actual class definition. Be careful when using the terms class, instance, and object, since they are not interchangeable and can lead to confusion.
An object can be easily stored in a PHP session. PHP automatically serializes the object at the end of the request and deserializes it when the session data is read on the next request.
session_start();
if (!isset($_SESSION['soap'])) {
$_SESSION['soap'] = doSoapRequest(); // Returns an instance of your class.
}
When an object is serialized, only the variables defined in the class are saved along with the name of the class. When it is unserialized, the class definition must be available (that is, either autoloader or explicitly included into the script). Unserializing will create a class instance with the same data as the object that was previously serialized.
Related
I have a pretty big PHP class instance with quite a lot of methods and potentially including semi-sensitive data that I would need to be able to access through AJAX. I've read about and successfully tested $_SESSION to transfer the class and object, but there seem to be some security concerns. Eg. see How safe are PHP session variables?, and PHP Session Hijacking.
Previously I 'solved' this by simply require'ing the class and re-instantiating the object on every AJAX call/ or making those methods I needed static (after checking for a token and a constant), but I feel like this should be quite performance-heavy (how long does it take for PHP to initialize an object which reads in 200+ JSON/XML files?).
Another option I see is serializing the data in a temp file, but really I have no idea nor experience of what is the best way to go from a performance vs security point of view... Any help will be appreciated, thanks.
I've inherited some PHP code that I need to make significant changes on. I know with PHP it is possible to serialize an Object, and pass the serialized text between pages as FormData. In the code I've inherited, they have done just that, But this is creating some maintainability problems. I'm wondering if taking this approach is even a good idea.
For example ...
When the user opens PageA.php the following is created:
$expensiveObj = new ExpensiveClass($id);
The $expensiveObj is then serialized and the resulting text is stored in a div with the following:
<div id="expensiveObj"><?php echo strtr(base64_encode(serialize($expensiveObj)), '+/=', '-_,');?></div>
When PageA.php loads, an ajax call is made to PageB.php. The content of the div is passed along as a post variable to PageB.php. Within PageB.php the following code unserializes the object:
$expensiveObj = unserialize(base64_decode(strtr($_POST['expensiveObj'], '-_,', '+/=')));
The fields and methods of the $expensiveObj are now accessible to PHP. The problems I'm encountering are
Because the $expensiveObj is not identified in PageB.php as an instance of the Class ExpensiveClass then the IDE doesn't know that the fields and functions of ExpensiveClass are available. I can't do autocomplete, nor lookup within the IDE what functions are available. Plus the IDE can't catch potential issues. The other developer worked exclusively in VI, so he never cared.
PageB.php needs to be re-factored. There is view, business, and controller logic all happening within this page, I would prefer to create a couple of classes, but I'm encountering a problem where I don't know how to pass the $expensiveObj to a class.
My questions are, is there a way to pass an Object to a class? And is there a way inform the IDE that the passed in post variable is indeed an instance of ExpensiveClass?
Lastly, is it even a good idea to be passing around objects this way, or should I be looking at a larger re-factor?
Storing objects directly in HTML is never a good idea, because it can be easily changed by client. In PHP is more common to create new object on every request according to given parameters. I see you are initializing your object using $id, so you can just pass this id between requests. Storing data to session also isn't best practice, session should be used for session-specific data, e.g. logged-in user etc.
If the creation of the object is very expensive, you can use cache, e.g. memcache, some external library or just to write your own, for example storing data in JSON on file system or in database.
I am coding my first CodeIgniter application (very familiar with PHP, but not CI) and have the following setup:
I have a controller, Signup, that controls a signup process. Every function of the controller is the next step in the process. I have an object, Did, that I am currently loading as a library. This object's properties/variables are updated as the signup process moves along.
The issue I'm having is that the properties from one function of the Signup controller do not carry over to the next function. It is as if the class is re-constructed with every function.
Is there a way to reuse the class throughout the controller without it having to be re-instantiated? I'd rather not have to serialize and store in a session, either.
Thanks in advance.
As always, there are many solutions to the same problem. Please disregard this if it doesn't fit well with your implementation.
Keeping the signup steps in an object is a good idea- however, every time you load a new page CI rebuilds all the objects. In order for data to persist it should be stored in the session, but that doesn't mean you have to be working with session variables in your controller.
How are you transferring data to your application? Is it via forms or ajax?
One way you can do it is by unserializing the object from the session and storing it as an object in your controller's constructor. That way you can still run $myObj->function() against it and use a $myObj->save() function to reserialize and store it.
Hope that helps!
The problem you are having is that you are depending on the in-memory state of your application to remain from request to request.
You're expecting your class to use the same instantiation of your Did object between requests.
This is not how PHP/HTTP works. Each request is handled individually and is it's own instance of your application. So each request creates a new Did object.
To persist the state you need to either use Sessions to carry information between requests, use a database to handle your persistent state, or a combination of both.
Codeigniter Sessions
Codeigniter Database Class
Im used to java and creating UML.. and i was wondering how can PHP be OOP, the objects live only until you make a request.. then they destroy, so if im using a database is useless to create a class and add the members (variables) to the class, they will be useless.. i cant pass the main system object from one page to another, or similar so how can PHP be compare to jave? you never do OOP .. i mean REAL OOP.. not creating classes , in fact your index will be a procedural file with some object instance and then ? how about if i make a html form and i want to submit the data.. i have to call a file which is not a class is a php procedural file were i grab the submited data with POST, from that file you will instance a class and do some logic there.. but for me thats not pure OOP.. can somebody point me to the right way of OOP using a form submit example ?
Thanks!
You're labouring under a misapprehension that object oriented programming by definition includes a persistent environment with objects that exist independantly of page requests. I'm afraid it doesn't.
PHP does do "real" object-oriented programming. But PHP's execution environment is like executing a CGI program: upon a page request, the program starts and it ends when the page is finished. Within that paradigm, objects can exist only as long as the page is producing content. Therefore, the first thing the page must do is to load the framework to define and instantiate the required objects, such as a database handler and object mappers that must load and save their data within a page request cycle. Some frameworks will also create objects with the page-request data that your code and objects can then access, sometimes from within objects.
But PHP does not provide this natively because it does not enforce a framework. It is by nature procedural so a framework must be added so as to define and create the desired objects if you don't want to work that way.
There is an advantage to doing things this way. It means a page's code need only concern itself with a single page request. Almost all issues to do with data-sharing and multiply-threaded execution is pushed out to things that can handle it invisibly, like the database and the web server.
Check out any of the latest php framework and how they handle forms. (like ZF or Yii).
b.t.w the "problem" you refer too is client-server architecture and not a minus of PHP.
Each request is a new process with a new MAIN or new Class with static main function which are practically the same.
"so if im using a database is useless
to create a class and add the members
(variables) to the class, they will be
useless"
It sounds like you want an object-relational mapper. There are several popular ones for PHP, as discussed at this previous question.
Is the Registry design pattern a good solution for this in PHP?
For a social network site (facebook, myspace).
let's say I have a Database class which creates a single DB connection and lets me do DB stuff and a Sessions class which lets me handle sessions as well as a Cache class which lets me cache items and retrieve them. SO that is 3 main classes that I will need to be able to access on every page of my site. After reviewing the Registry Pattern for the past hour, I am thinking that it is the perfect solution maybe. I can store my Database, Session, and Cache objects into a registry Object and then Inject the Registry object into every page or every other class and have access to my database, sessions, and cache.
Before this I was using a singleton pattern so I would have to call my singleton method for all 3 of my MAIN classes inside of every page or other class.
So I am just wondering is there any downfalls of using the Registry class? 1 that I can see is it seems it may be harder to see what classes depend on which other classes and such. Other then that it seems like a great solution for this, also I saw another post on here of a user's registry class where they were storing setting in the registry an having access to them in all the other classes that the registry Object is passed into, I am sure I will find a good use for that feature as well.
So the only question here is am I missing something or did I just hot the lotto?
UPDATE
Also if using a registry to store objects in, should I do something like this...
$this->session = $registry->getObject('session');
or this instead
$this->registry->session = $registry->getObject('session');
The second method seems like it would maybe be easiar to understand where the object came from?
You mean a registry of Singletons, right? If so, it sounds like all you really want is access to three global objects everywhere, but contained inside another object.
So if you wrote cache.php, sessions.php, and database.php, which define the classes Cache, Sessions, and Database, you want to contain them all inside a Registry object defined in registry.php.
First of all, it's great to control the ORDER of instantiation this way. It's better than simply doing a require_once of cache.php, sessions.php, and database.php, and inside of them you define not only the class but the single global instance of it. That controls the ORDER of instantiation by how you include/require it. Kind of sleazy. Better to have your Registry object, that when it gets created and becomes a $registry global, first thing is does is control the creation of your globals in the order and how you want.
Second of all, it's great to have a single Registry.php that has a single $registry global. Defining globals here and there over various files gets hard to manage.
Now that I've agreed with you, I pose an important question to you. How do you see these being different:
$registry->getObject('session');
$registry->getObject('database');
$registry->getObject('cache');
versus:
$registry->getSession ();
$registry->getDatabase ();
$registry->getCache ();
Personally, I like the latter. You aren't using a string "session" to refer to a Session object, obtained through a super-generic getObject. Instead, you are using getSession() to get a Session. It reads better.
Your registry, after all, knows all about the three globals, it creates them explicitly, so it's already locked into a single purpose. Adding concrete methods also tied to its single purpose isn't "weak" or "bad". Instead, I think it's less code and easier on the eyeballs.