sscarpa / google-api-php-client

Automatically exported from code.google.com/p/google-api-php-client
Apache License 2.0
0 stars 0 forks source link

Remove the use of global #154

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago
What steps will reproduce the problem?
1.Simply looking at the code base
2.Attempt to use the PHP google API on a server with the default setting for 
register_globals(off).

What is the expected output? What do you see instead?
A working usable API.
An unfit for production usage script.

What version of the product are you using? On what operating system?
I wrote my own integration as a result of what I see in the code simply to have 
CLEAN code.

Please provide any additional information below.

Original issue reported on code.google.com by marchert...@gmail.com on 9 Jul 2012 at 6:04

GoogleCodeExporter commented 8 years ago
if it is at all unclear what I speak of, I speak of code like:
global $apiConfig;

Original comment by marchert...@gmail.com on 9 Jul 2012 at 6:12

GoogleCodeExporter commented 8 years ago

Original comment by chirags@google.com on 9 Jul 2012 at 9:02

GoogleCodeExporter commented 8 years ago
Hi,

Here's a backwards-compatible version of the API client with no need for the 
global keyword, and where the config.php file has become optional. To retain 
backwards-compatibility it does still use a global variable, but i the form of 
$GLOBALS['googleApiConfig'] — which is set in the Google_Client __construct() 
method, doesn't require explicit scoping, and isn't affected by 
register_globals, etc. 

The bulk of the flow happens without need for the googleApiConfig settings, but 
I needed to keep that in order to support the useObject and baseDir lookups in 
/io and a few of the /service objects. 

Note that the config is passed directly to /auth and /cache objects. That's 
here, line 181 of the Google_Client object:

self::$cache = new $cache_object_type($this->googleConfig);
self::$auth  = new $auth_object_type($this->googleConfig);

Basically I wanted to clean up some of the structure without breaking any of 
the current usage. I'm sure you have plans, but my thinking was that this would 
allow a migration to new usage patterns without compatibility issues, and a 
larger refactor could happen down the road if folks weren't satisfied with 
these changes. Hope it helps!

(Double-checked that I attached all modified files, but let me know if a zip 
would be more help.)

Original comment by je...@cashmusic.org on 19 Dec 2012 at 8:53

Attachments:

GoogleCodeExporter commented 8 years ago

Original comment by ianbar...@google.com on 22 Mar 2013 at 2:27