If you are a ZF beginner longing to contribute with new modules for Zend development, the idea is pretty realizable. You just need to create something really good and helpful. For this you’ll need your passion, knowledge, and the following 9 rules of writing ZF modules.
Rule 1. Check for existing modules
Before writing anything it makes sense to check if there’s already the same module created by somebody else. You don’t want to waste your efforts, so it’s much more useful to just improve the existing module if your idea has been already implemented.
Rule 2. Respect conventions
Zend Framework development, as with any other framework, follows some strict coding conventions which you should also respect. Aside of these, there are also some other common standards, such as on where you should locate files.
For example, there are many configurable modules. If a module has a lot of options, a good idea will be to centralize those into the Options class. Similarly, some people prefer putting a whole lot of files into a single folder making the files difficult to find. So don’t be lazy and make it a rule to create a new folder when you need it.
Rule 3. Allow for configuration
You want your module to be used and shared by other people, right? But people’s needs may differ from yours greatly. That’s why whenever you think your module users would like to modify something in it, add options to let people modify that thing.
Rule 4. Set hard dependencies in constructor, not initializer
The ZF 2 service locator really enables a clean handling of complex dependencies by mocking. While this tool is quite powerful and not very hard to use, ZF 2 also has initializers you must have met already under the names EventManagerAwareInterface or ServiceLocatorAwareInterface. When some class implements these interfaces, the dependencies are automatically injected by the service manager. While this facility is nice, there are some problems associated with it that can cause much pain and bad experience for the module’s users.
Rule 5. Avoid using closures as factories
Handling dependencies by means of closures used as factories in your getServiceConfig of the Module.php class is common practice. But it’s recommended to implement explicit class factories instead since this is a bit more efficient, allows for caching config file and removing the unreadable Module.php with its tons of closures.
Rule 6. Put dependencies with service manager
Closely following Rule 3, people sometimes want very weird things. While you’ll let them configure your module, you are hardly going to add that feature to the module’s core. But you can at least help him by making it easy to override everything. ZF 2 architecture enables doing this simply by creating most objects via the service manager.
Rule 7. Write unit tests
Boring as it can be, unit testing your module is a must if you don’t want pain in the ass from untested modules. Unit testing is important because whenever you update your module, you’ll find the whole app has failed as your upgrade broke something. And it’s even more the case with modules designed for professional use.
Rule 8. Host on Packagist
For handling dependencies between the modules, many use Composer. You may not like it, but if you want your module to be shared by many people and it’s good enough, post it on Packagist.
Rule 9. Set dependencies only on required components
As ZF 2 is one of the modular frameworks, thanks to Composer, users don’t have to download the framework fully to use it. Thus, they won’t be happy if you require them to make a full ZF download to access your module. That’s why rather than setting a dependency on the whole framework, do it only for specific components that are necessary.
Please feel free to add your own tips!