class magic {
public $method = "";
function __construct($m){
$this->method=$m;
}
public function info($name){
if($this->method === 'get'){ // = is asssignment, == is same value, === is same value and same type
$this->$name = $_GET[$name];
return $this->$name;
}
}
}
// spoofing a get var
$_GET['newyear'] = "Happy new year";
// instantiate and set the method
$m = new magic('get');
// look for a value assuming it is set
echo $m->info('newyear');
I’m presuming you are just testing out some OOP syntax, because this kind of magic class which obfuscates where a REQUEST var has originally come from is rarely a good idea. Its tempting to do, I agree, I did the same one – and lived to regret it.
I’m not sure I entirely agree with Cups, It’s not really a good idea to use $_GET/$_POST at arbitrary points throughout your code and abstracting that can be a good idea. That said, passing around a object which simply contains them in another format isn’t much better.
Using calls to $_GET and $_POST heavily reduces flexibility. Are you sure you always want that variable to come from $_GET? You severely limit reusability by making that assumption. As such, the top level of your application should have access to $_GET/$_POST and pass on the required variables to functions that need them. The functions which actually do any processing involving the variables should be totally agnostic about where they originally came from.
Yes, I don’t see any point in creating a class for accessing GET/POST (unless you want to implement some advanced filtering methods). Like TomB, I believe the values should be passed to other functions and objects.
But at times I have done some minimal abstracting of GET/POST by writing the values to a $request variable (array) and then when I call controllers I pass $request to them and they don’t read $_GET/$_POST directly but fetch values from $request. Sometimes this allows me to call a controller from another controller and feed it my desired request values without affecting the $_GET/$_POST superglobals. I’ve heard it’s not a good idea to reuse controllers but anyway I do it vary rarely.
Controllers shouldn’t ever need to be chained in this way because controllers should just take user input and use it to set the model’s state. If you’re chaining like this what you should really be doing is setting the model’s state from the active controller and rendering the required view. If you’re finding the need to call controllers, it almost certainly means you have model state and/or logic in the controller.