I want to include Google Cloud in one of my webprojects which is based on Codeiginiter.
Now my big question is, how to implement the Google API PHP client into CI?
Since CI is a MVC framework it wouldn't make sense including it directly with require_once in the view, so I thought about creating a library but that means a lot of work.
Does anyone know a better solution or maybe a fitting CI library?
Thanks.
This can be implemented by creating a simple library by extending the Google_Api
some thing like..
require_once /path/to/Google_Api/file_name.php
Class my_google_api extend Google_Api
{
// constructor
}
Now load this library to your controller and the access all the methods from Google_api
You can use composer. CI supports autoloading of third party libraries with composer. Besides, usage of composer is a preferred method to install Google APIs Client Library. In this way you won't need to include the library with require_once, all the modules will be loaded automaticly by composer's autoloader.
Related
Is there a existing module or file to manage autoloading of sdk classes when using PHP GAE ?
This would avoid to require a file when using a class of the google sdk.
Thank you for any clue.
No nothing yet - we're investigating if this is something we want to do provide out of the box.
I played with the zf2-tutorial successfully, but I was totally confused when trying to integrate an external library like "jpgraph". I know I must do this with autoload or servicemanager but it won't work.
The php-files of jpgraph are in the vendor/graph directory. I use a module called Jpgraph, in the controller indexAction I try:
$graph = new Graph($width,$height);
this gives me an error:
Fatal error: Class 'Jpgraph\Controller\Graph' not found in ...
the jpgraph library don't use namespaces.
i also tried this way without success
what's the best way to integrate such things?
I would be glad for every tip or help
Add the library to your composer.json and add the class with Classmap and/or the include path as phpunit does
https://github.com/sebastianbergmann/phpunit/blob/master/composer.json#L48
One option, as Maks3w pointed out, is to use Composer. If you've never heard of or used composer before it's definitely worth a look. I was surprised how easy it was to set up and use 3rd party libraries. It's also very easy to set up your own library to work with composer, and use any source controlled (git or svn) library of your own - works well with GitHub repos - just add a composer.json file.
On the other hand, you do not need to use composer to do what you want, it would make it very easy, but it may be overkill. Zend Framework 2 has a very flexible autoloader system, and although it works well with PSR-0, you can have any class autoloading sytem that you like. Take a look at the different components of Zend\Loader, in particular I think the ClassMapAutoloader will be the one to suit your needs.
When building a library I always provide an Autoloader class that handles autoloading for the library. The autoloader is registered like this:
require_once 'path/to/PHP-Parser/lib/PHPParser/Autoloader.php';
PHPParser_Autoloader::register();
I'm not sure though how to handle it if my library depends on another library. Imagine that PHPParser depends on a PHPLexer. Now when using the library one would need to write:
require_once 'path/to/PHP-Lexer/lib/PHPLexer/Autoloader.php';
PHPLexer_Autoloader::register();
require_once 'path/to/PHP-Parser/lib/PHPParser/Autoloader.php';
PHPParser_Autoloader::register();
If there are more than just one dependency or the dependencies have dependencies themselves, this can get messy quickly.
So how should one handle dependency autoloading?
One idea I had was that the library should handle autoloading for it's dependencies too, but that just doesn't feel right. Another idea would be to not provide an autoloader at all and assume that people use the UniversalClassLoader. That though doesn't seem right either.
Well, there are a few ways to solve this problem, each with their own pros and cons:
Use a common PSR-0 autoloader for all the libraries, and just register the location of the other project when initializing it.
Advantages:
Very simple to implement
Uses same code, so only one autoloader to use
You can register all the paths in your application bootstrap file, so all library autoloading is defined in one place
Disadvantages
Requires all libraries to implement a PSR-0 compatible file structure
Leaks the abstraction level a bit since the application bootstrap needs to bootstrap everything inside the application including each individual library.
Tightly couples the library's file structure to your autoloader (if a library implements a new file that conflicts, it'll break your autoloader even though theirs works file)
Define a custom autoloader for each library.
Advantages
Very simple to implement.
Keeps library autoloading semantics in the library.
Better maintainable code due to separation of responsibility
Disadvantages
Lots of hard-coded classes in your bootstrap file (not a big deal though)
Performance since an autoloaded class must go through multiple autoloaders
Leaks the abstraction level since a library may need more effort to bootstrap than just an autoload
Implement a bootstrap.php for each library (preferably provided by the library)
Advantages
Pretty simple to implement.
Keeps library autoloading semantics in the library
Better code due to separation of concerns
Ability to define non-trivial library bootstrap code without clouding other parts of the application
Disadvantages
Still require a require_once '/path/to/lib/dir/bootstrap.php'; to initialize
Performance (for the same reason as the 2nd solution)
Most 3pd libraries do not implement a bootstrap file, so you may have to maintain one.
Personally, I use the third option. An example is the bootstrap.php file in my CryptLib library. To initialize it, just call bootstrap. You could also use any PSR-0 autoloader and just not call bootstrap.php, and it will work just fine. But with the bootstrap option, if I added functionality which needed to register itself at startup, I could just add it to the bootstrap.php file and it would automatically be executed (rather than telling users that they will need to do "x, y, z" on startup)...
With respect to the universal class loader option that you mentioned (calling spl_autoload_register() with no arguments), I personally don't like that option. First of all, it lowercases the classname (which is in violation of PSR-0, and I don't like it. I have gotten used to case sensitive class -> path mapping, and actually prefer it that way now). Secondly, it always uses relative paths, so it will defeat most opcode caches. There are other issues, but those are the big ones...
If classes in library named by PSR-0 convention, than it's possible to use one autoloader for all libraries. Otherwise, library should provide own autoloader.
add to class constructor
public function __construct(){
$this->Register();
}
after that on page where you whant to make load create an object
$obj = new PHPParser_Autoloader();
I want to use a small library within the Zend Framework (simple_php_dom, for what it's worth).
Should I just stick it in library/, include it where I want to use it (like in a specific controller) like include('library/foo.php'); and have at it?
If not, how should I do it? What's the "Zend Framework" way of doing something like this?
Since the library doesnt support PEAR conventions its not really easy to hook it up to the autoloader, so i would just manually require_once it in the controller or model that uses it. If it was used extensively I might make a wrapper class to proxy calls through and autoload that (that class having the require_once).
I've downloaded the Zend GData package to use the Google Calendar API. When I look through the contents of the package it seems to contain loads and loads of stuff. Do I really need all of it just for using Google Calendar and no other Google APIs? If not, what can i safely get rid of?
You probably won't use many of the files in Gdata folder, but Zend_Gdata_Calendar extends the Gdata class, and Gdata extends Gdata_App which uses Zend_Http_Client (and a few other classes) to (essentially) make requests to google. Loader loads classes, Registry stores objects/data, and so on. So, yeah, many of the downloaded files will be used. You could of course rewrite much of the code to use only the parts you need, but that kind of defeats the point of using the framework.
I'd recommend building a prototype of your application following the tutorials on Zend but with all the library in place. Once you can see how it works, you can more easily rip what you don't need. At least it's just the Gdata library and not the whole 64MB full framework :D