2 Housekeeping… • Me Sr. Web Architect Manager at NOOK Developer Open Source Contributor Where you can find me: • Twitter: mwillbanks G+: Mike Willbanks • IRC (freenode): mwillbanks Blog: http://blog.digitalstruct.com • GitHub: https://github.com/mwillbanks
11 RFC March 2012 “RFC Service Components” Removal of ZF2 Zend\Service namespace into a separate namespace (ZendService) and under their own GitHub project.
Goals of ZF2 Service Components • Ability to version separately from core framework • Easier to leverage outside of a ZF context • Encourage service providers to further contribute
Services for Contribution (Official Services) • Independently versioned • Dependencies on framework versions (2.*, 2.0.*, 2.0.1) • Maintain dependencies by specific packages • Must follow ZF coding standards • Must be unique A service that does the same thing should not already exist!
Service Component Maintenance • Must be maintained for the duration of major versions Exceptions must be noted in the ChangeLog Component should only state dependency on minor versions • Maintainers must attempt at all times to keep compatibility with the latest version If unable to maintain, actively recruit, if still unable ZF or CR team will make a recommendation on the component.
General Information • Service Components are really just like framework libraries However, the namespace implies 3rd party integrations. They are also organized like the framework. • Service Components should be reusable for other developers Write it out based on the API and not just what you need. • Create reasonable dependencies Zend\Http and Zend\Stdlib being most common.
Why Not Modules? • Modules are more specifically for ZF2 Applications • Service Components are reusable libraries for any code base. • Base Rule If it involves the MVC; it should more than likely be a module.
Unit Testing • Quick Start Clone an existing Service Component (Currently no skeleton) Copy over files from the tests directory: _autoload.php, Bootstrap.php, phpunit.xml.dist, TestConfiguration.php.dist, TestConfiguration.php.travis • You will need to customize phpunit.xml.dist – Change out the unit test name. TestConfiguration.php.dist – Configure your constants and configuration.
Unit Testing • Tests should contain proper name spacing ZendServiceTest\Google\Gcm • Files you need should be located in an _files directory inside the test area of your component tests/ZendService/Google/Gcm/_files • Write unit tests like normal!
Library Code! • The guts of the library is what most of us are familiar with • Write your library inside of your compliant directory library/ZendService/Google/Gcm • Ensure proper namespacing ZendService\Google\Gcm • Attempt to follow great naming so that it makes sense!
Coding Standards • Remember to make use of the coding standards! Docblocks Import the proper packages from their respective namespaces Read the coding standards doc: • http://framework.zend.com/wiki/display/ZFDEV2/Coding+Standards • Mainly; PSR-0, PSR-1, PSR-2 (there are slight differences)
Best Practices • Follow conventions PSR-0/1/2, file locations, options classes • Hard dependencies Use the constructor! Only set dependencies for items you require! • Write Tests Hook into Travis-CI, go for 100% code coverage • Discoverability Put the component on Packagist, submit it for inclusion to ZendService.
Documentation • The most dreaded part of the job… • All of the documentation is in the “zf2-documentation” project under the “zendframework” github organization. This will likely change for services in the future. • Fork the project • Create a feature branch: feature/service-google-gcm • Write your documentation • Submit a PR
36 Seeing your Documentation • Install the proper tools apt-get install python-setuptools python-pygments easy_install -U Sphinx • Enter the docs/ directory • Run: make html
Integrating your Service Add the module to the composer configuration Add in potential configuration Setup the service manager Fetch it inside of a controller