I’m a slacker

So, I haven’t made a post in over a year and I feel so bad I want to do an awesome post to make up for it. So, behold, a quick & dirty summary of all my available ZF2 modules. I tend to jump around from module to module depending on my current needs so I’ll try and list the state of each module.

The Modules

I’ll list each module in descending order from how useful I personally think they are. Your own mileage may vary. As always, I’m accepting PR’s so if you want to contribute please do so!

SpiffyNavigation

is aimed to be a replacement for Zend\Navigation once ZF3 comes around. I used a RecursiveIterator with composite pattern to make traversing containers quick. This makes SpiffyNavigation very performant!

It’s missing some view helpers and a few other features like priority but overall it’s pretty solid.

Tests: Yes
Documentation: Yes
Production ready: Yes

SpiffyConfig

is my newest module which is not ready for production but came from my previous work on . The goal of SpiffyConfig is to expedite configuration via annotations without sacrificing performance. It’s hard to explain this one so I’ll use a few examples:

namespace Application\Controller;

use SpiffyConfig\Annotation\Controller;
use SpiffyConfig\Annotation\Route;
use SpiffyConfig\Annotation\Service;
use Zend\Mvc\Controller\AbstractActionController;

/**
 * @Controller\Invokable(name="index")
 * @Service\Invokable(name="index", key="controllers")
 * @Route\Generic(type="literal", action="index", name="home", mayTerminate=true, options={"route":"/"})
 */
class IndexController extends AbstractActionController
{
    public function indexAction()
    {
    }

    /**
     * @Route\Literal("/child1", parent="home", name="child1")
     */
    public function testAction()
    {
    }

    /**
     * @Route\Segment("/child2/:id", parent="home/child1", name="child2", mayTerminate=true, options={"constraints":{"id":"\d+"}})
     */
    public function anotherAction()
    {
    }
}

I know that’s a lot of stuff to figure out but give me a few days and I hope to have some documentation up that explains everything.

Tests: No
Documentation: No
Production ready: No

SpiffyAuthorize

 aims to be a replacement for ACL/RBAC solutions by implementing into them into a single code base. Right now, only RBAC is setup, but I’m open to PR’s from anyone wanting to add ACL implementation.

Tests: Yes
Documentation: Yes
Production ready: No

SpiffyCrud

 is a solution for RAD of CRUD operations. I took some ideas from Django’s admin tool and tried to come up with a system that is easy to use but also offers full customization should the need arise.

Tests: No
Documentation: Some
Production ready: No

SpiffyDatatables

is a thin wrapper around jQuery Datatables and is used as the default renderer in SpiffyCrud.

Tests: No
Documentation: No
Production ready: Yes

SpiffyTinyMce

is a thin wrapper around TinyMCE.

Tests: No
Documentation: No
Production ready: Yes

SpiffyConnect

is a module I wrote to replace HybridAuth because anyone whose worked with HybridAuth knows it’s a gigantic pain in the ass. It features a simple, consistent, API for multiple providers. I was building this for a work project which was canceled so I stopped development but the core features are in and I would love to pick this back up at some point.

Tests: No
Documentation: Some
Production ready: No

SpiffyUser

is YAUM (Yet Another User Module). I was working on a rewrite of ZfcUser but supporting multiple backends is a problem that is not easily solved so I instead chose to focus on Doctrine and PHP 5.4 to take advantage of traits and the power they bring to Doctrine. That said, it is possible to get SpiffyUser working with Zend\Db if you create your own ObjectManager and ObjectRepositories.

SpiffyUser aims to keep a very slim core and provide features through the use of extension modules. The entire API is heavily event driven. All extensions are enabled if installed and disabled if uninstalled. This reduces the need to modify configuration.

If anyone wants to pick up the work I did on ZfcUser all the modules are available on my GitHub. Feel free to fork them and take them over.

Tests: No
Documentation: No
Production ready: No

SpiffyUserRemember

 is an extension for SpiffyUser that provides simple remember me cookie support.

SpiffyUserMetadata

 is an extension to provide additional user metadata. This extension is no longer required due to the architecture of SpiffyUser but I left it listed for brevity.

SpiffyUserAuthorize

 integrates SpiffyUser and SpiffyAuthorize into a unified system.

SpiffyTest

is a simple module that bootstraps the Zend\Mvc\Application and Zend\ServiceManager\ServiceManager and provides custom module.config.php and application.config.php files for use in a testing environment. Most of my modules that have tests use this as.

Show & Tell

Combining SpiffyConfig, SpiffyCrud, and SpiffyDatatables into one system let’s me do the following.

namespace SpiffyPage\Controller;

use SpiffyConfig\Annotation\Controller;
use SpiffyConfig\Annotation\Route;
use SpiffyCrud\Controller\AbstractCrud;

/**
 * @Controller\Invokable
 * @Route\Generic(name="spiffypage.admin", type="crud", options={"route":"/admin/pages"});
 */
class PageAdmin extends AbstractCrud
{
    /**
     * @var string
     */
    protected $modelName = 'SpiffyPage\Crud\Model\Page';

    /**
     * @var string
     */
    protected $route = 'spiffypage.admin';
}

 

namespace SpiffyPage\Crud\Model;

use SpiffyConfig\Annotation\Service;
use SpiffyCrud\Model\AbstractModel;

/**
 * @Service\Invokable(key="spiffy_crud|manager")
 */
class Page extends AbstractModel
{
    /**
     * @var string
     */
    protected $displayName = 'Pages';

    /**
     * @var string
     */
    protected $entityClass = 'SpiffyPage\Entity\Page';
}

 

In Closing

I hope you enjoy using ZF2 as much as I do! If you have, or are considering writing, a module that is similar in scope to any of the ones I listed above please consider contacting me or submitting PR’s so that we can collaborate. Two heads are better than one! Also, I listed several modules above as not ready for production primarily due to the lack of tests and documentation but every module listed above does function.

As ZF2 increases the beta count and draws nearer to RC I’ve noticed more questions popping up in IRC regarding configuration. Questions like:

“How do I setup XXX?”
“Where do I add module options?” 

So, I decided to write up a quick blog explaining how configuration works in ZF2. By default, there are three types of configurations.

• config/application.config.php – This configuration file is at the “lowest-level” and is primarily responsible for setting up the service manager and module manager (see index.php). This is the file you will add modules to but, beyond that, will have little interaction with.
• module/{ModuleName}/config/module.config.php - These configuration files are “middle-level” and are used to configure a specific module. The general rule of thumb is that any module living in vendor/ should not be modified – this includes the configuration! Since I know you want to reuse code and reduce duplication you should have plenty of vendor/ modules. Feel free to edit the configuration in your own modules but keep a goal in the back of your mind to get to a point where the configuration changes only for application specific options!
• /config/autoload/{,*.}{global,local}.php – Woah, Spiffy, what’s up with that crazy path? Well, that’s a glob pattern and it’s used to determine which configuration files to load as well as the order to load them in. These files are considered the “highest-level.” By default, the glob is exactly as I pasted it and that pattern will load any file in config/autoload/ that ends with global.php or local.php. You’ll notice that global is listed before local which is important because it means that your local configuration files will override your global configuration files. This is a good thing! It means you can have development/staging/whatever configuration files in *.local.php which will override your global production files. It’s important to remember not to commit your local config files!

The reason I assigned levels to the files above is to help illustrate how these files are loaded. The application.config.php file is loaded on bootstrap and, after that, is not used. The module configuration files are merged through magic into a condensed merged config which is available from the module manager as well as the service manager under the Configuration service.

The load order for modules is as follows:

1. Merge together all modules configurations into one array. In general, the order of modules does not matter but it’s possible that you may have a situation where one module overwrites another. If this happens, you need to make sure you list the modules in application.config.php in the correct order. At the time of this writing, I know of no third-party modules where ordering in application.config.php matters so I don’t have a concrete example for you.
2. Resolve the files from the glob pattern and merge those files in order with the module configuration.

To summarize:

• There are three primary configurations by default: application.config.php, module config, and autoloaded configuration.
• The order is: modules -> config/autoload/*.global.php -> config/autoload/*.local.php => merged configuration
• If you want to override module settings to do it in the autoload/ files! Just remember that you should not commit your local configuration files.
• The glob pattern is specified in the application.config.php file if you want to modify the default.

Many web applications share features – user management, templating, ACL, blogs, etc. ZF-Commons’ goal is to to produce high-quality, reusable modules for many common tasks that web developers face. Currently, we have a handful of modules available:

• ZfcUser - A generic user registration and authentication module for ZF2. Supports Zend\Db and Doctrine2.
• ZfcAcl - A generic and flexible ACL implementation for ZF2.
• ZfcTwig - Zend Framework 2 Module that provides a Twig rendering strategy

I encourage you to check them out, post feedback, and to submit your PR’s and bug fixes! Let’s stop creating wheels and combine our efforts to create a single bad ass wheel instead.