Category: Zend Framework

Documentation for everything

Hello fellow geeks!

Today I’d like to share a nice piece of software that has boosted my productivity by 200%. It’s a tool that allows you to download documentation from a lot of libraries, frameworks, programming / scripting languages, stack overflow, packagist and more. It’s called Dash (for mac) and Zeal docs for Windows / linux. For this post I will be talking about Dash specifically, but most of it also applies to zealdocs.

What it does

Like they say themselves:

Dash gives your Mac instant offline access to 150+ API documentation sets.

It integrates with the system (shortkey) and a lot of editors / other systems. As an example, in your editor, you can select some text (for instance, Angular’s $http) and push the shortkeys for Dash (defaults to cmd+shift+d), which will bring up the documentation on $http for angular.js. Are you writing php, and are you unsure on what strstr or stristr do? Select that, press the shortkeys and boom, documentation.

Like I said, it has documentation for a lot of things. Node.js, PHP, javascript, ruby, Zend Framework 2, Laravel, and much, much, much (I can keep going like this) much more.

It also supports Packagist and automatically builds documentation for all packages you wish to use, if there aren’t any. And it supports stackoverflow by downloading answered questions which you can search.


It’s offline, fast, has everything in one place and doesn’t force you to wait for the browser. It’s just cool. Check it out:

Mac: Dash

Windows/Linux: Zeal docs

Zend Framework 2 modules

About a week ago SpiffyJr created a post on his blog outlining his modules and their state. I quite liked the initiative, and felt like following up on this (what I hope to become) trend.

The reason I feel this is a good idea, is because there seems to be a lot of duplicate module creation. Zend Framework 2 developers don’t always realise something already exists, so decide to build something themselves. This is a waste of time, efforts and talent, which are all things I hate wasting. For this reason, I’ve compiled my own list of modules. So following is a description of my modules.


Most of my modules reside under the SpoonX organisation. The modules that make it to the organisation are stable, or at least complete enough. Currently, the only module that’s stable but not under the spoonx namespace, is the AssetManager module.




As perfectly described in the readme:

This module provides functionality to load assets and static files from your module directories through simple configuration. This allows you to avoid having to copy your files over to the public/ directory, and makes usage of assets very similar to what already is possible with view scripts, which can be overridden by other modules. In a nutshell, this module allows you to package assets with your module working out of the box.

On top of this, the module also allows you to apply filters, apply caching, create collections, create custom resolvers, create custom filters and create custom cachers.




This module is a wrapper for twitter bootstrap. It comes with some neat features allowing you to do some cool things.

Features (as taken from the

  • Simple awesome forms (group action controls, create horizontal forms etc)
  • Fast
  • Customisable (variables, components, plugins. No more downloading zip files!)
  • Works with the AssetManager
  • Plenty of ViewHelpers
  • Extendable (run your own less files from bootstrap context to share mixins and variables)




There’s not much to this module. It’s a plugin for SxBootstrap that allows you to easily create stunning wizards.




This is (currently) a very small library. It has two components.


The HtmlElement is pretty neat, it allows you to easily create markup using php. This is especially useful when creating viewhelpers; which is the reason it’s being used by SxBootstrap so intensively.

I started writing this component because of the annoying way Zend\Form\Element were written, and the restrictions they had. I was constantly messing around with strings (eww) and found myself unable to add ng- attributes due to restrictions (which, if you’ve ever used angular, is extremely annoying).

You can find some examples here.


This neat little component allows you to extract excerpts from bundles of markup without breaking the tags. This is really useful when it comes to, I don’t know, writing a blog (Yes, I’m hinting at SxBlog).




This module makes it incredibly easy to set up mailings. It does all of the boring work for you, and supplies useful functionality such as using ViewModels as templates and wrapping those templates in a layout. It also allows you to set up multiple configurations for multiple mailings, which will be merged with the default configuration (marked by the “default” key).

Features (as taken from the

  • Easily configurable. Both messages and transport.
  • Use ViewModels
  • Layout support
  • Mimepart detection
  • Easy header configuration
  • Access to Zend* classes
  • Generates alternative (text) body
  • 100% code coverage
  • Scratches your back after a long day of work
  • Makes a good drinking buddy.




This module is an attempt at creating a skeleton blog for minimalist bloggers (such as myself). It already includes a handful of features, but isn’t complete yet.

Here’s a screenshot of it in use:




This is not really a module. It’s basically a skeleton module (yes, I know, the repository name sort of gave that away) that allows you to easily start a new Zend Framework 2 module. It includes a license, composer.json, a module structure and basic tests. It’s easily used by running the setup script that’s bundled with it.

The following is the easiest way to get this up and running: git clone; cd SxSkeletonModule; ./ Username ModuleName; cd ..;

Note: Make sure you change the Username and ModuleName to yours. It’s used for the composer.json (and more files).


Writing this post took me quite a while but it was worth it. I hope it’ll help a developer or two. Building modules is awesome; but nothing’s as satisfying as watching people use, and enjoy using them.

There are obviously a lot more modules out there. A while ago Hounddog created a Zend Framework 2 modules application for which I helped out with the styling. It’s a really neat resource if you’re looking for modules, and I strongly suggest you submit your modules, too!

Happy coding!

Redirecting from a controller in ZF2

Hey all. Today’s post is a response to a question asked today on IRC.

The question:

In zf1 within a controller I could do something like $this->getResponse()->setRedirect(‘/foo/bar’, 201) ~ How do I do that using zf2?

The answer:

Controllers have plugins, not much has changed there. Except for the fact that it’s now even easier to get a redirect going. Check this out:


It also has a toUrl method, which behaves the same way:


Counter question:

Can you send a statusCode with that though?

Counter answer:

Yes, you can. As seen here, the redirect returns a Response. A response has a setStatus code, thus allowing us to do this:


Happy coding 🙂


Asset manager module for zend framework 2

Not very long ago I published the first stable version of the AssetManager module for Zend Framework 2. The purpose of the module is to allow you to package assets with your module, in stead of having to mess around with symbolic links, aliasmatch or mod_rewrite. On top of that, this module also gives you some other functionality such as caching, grouping assets and applying filters to your assets. You can add custom filters, custom cachers and custom asset resolvers.

RequireJs followup : The creation of a module


Last time I wrote about a possible require JS module for zend framework 2. After receiving a fair amount of interest, feedback and suggestions in general I decided to give it a go.

I proceeded to spend a decent amount of time reading all of requirejs’s documentation, mapping out how I’d like to fit that structure into the zend framework modular structure. It’s pretty much the same as described in the previous blog post, with only one big change… I’ve actually written the code. I know, shocker right.

So now what?

Well, I know this news might not be as interesting as I hoped it would be, but it is something. By publishing this blog post I’m hoping to receive more feedback, and perhaps some nice PRs. I’ve written some usage examples in the wiki in case you’re interested.


RequireJS (from here on RJS) did an awesome job supplying a modular structure. However, when working with ZF2 you’re already in a modular structure. This means we’re bound together with other modules if we want to share RJS modules. Every ZF2 module’s RJS module should have the possibility to get executed. Imagine having a RJS module that doesn’t get executed because the main application doesn’t know about it. That would take away a lot of flexibility.

I kept in mind that every module should share the same config map when it comes to loading RJS modules. This means that one way or another, we’ll still need a main application to provide all modules with this information.

SxRequireJs sets up a main application, which essentially sets all “module bootstraps” as a dependency, waits for them to load, and then executes them. This will be your module’s entry point, and should have its own dependencies.


Yes yes, I’ll stop talking. But I’d like to ask all of you to take a look, leave feedback and / or submit improvements.


RequireJS implementation for Zend framework 2

I have written a followup on this post, where I explain that the module is already available.

This is my initial idea for a requireJS module that could be used in zend framework 2. There’s not a lot of details yet, but the logic is there. Implementing this will be the easiest part, as I do believe that the architecture for this should be just right because you otherwise lose the flexibility and structure that both zend framework 2 and requireJS offer. I guess I’ll just start of by explaining my personal zend framework 2 architecture a little bit.

I do not store all of my assets in one directory. 

My approach is slightly different, in the sense that I supply assets on a per module basis. Every module has a public directory, and I use AliasMatch and RewriteEngine to map requests to their assets:


So basically I rewrite requests from this “/mymodule/js/main.js” to this “/path/to/application/module/Mymodule/”. This way my modules actually supply their own assets.


The reason I started using requireJS should be obvious to everyone that knows what it is.

In case you still want to know why,  it’s because I like structuring and setting up dependencies in a proper manner. This allows me to have a “main” module that will take care of global modules / dependencies such as jquery, allowing me to quickly scan for modules that don’t support jquery1.7.3 yet (example).


The problem with requireJS is the structure it expects.

With the way zf2 modules are set up the optimizer will not work. Also, being able to have one entry point (for the “main” requireJS) will be rather difficult with a bunch of modules having their own “main”. This could be solved by mapping those to the main application but then you’d not be working modular.


My solution is an implementation that will figure all of this out for you.

I was thinking of building a zf2 module with a viewhelper that allows you to register a path for your zf2 module as well as the main requireJS module. zf2 modules register requirejs modules, and at the end of the run the viewHelper will simply set up the requirejs config (paths, so that /zf2module/* links to the actually resource) and dependencies to make sure that all requirejs modules get loaded.

When enabled, this run could also automatically create a build file for requirejs. This, however, will work event based (zf2) and will ask every module for their requirejs modules (because a build takes all js). This allows you to leave out very specific requirejs modules from the build. Along with this approach, you could also have a build.json / build.js for every zf2 module which would be scooped out by the optimizer (a zf2 layer that will create the build file based on these files).


The reason I think this approach is awesome is because of its flexibility.

Simply because using this approach allows you to not have to think about your structure too much (the main goal behind requireJS and zf2 modules) and focus on doing what you know, thus your logic. It’s flexible enough for you to write your own implementations and use this the way you think fits best, while still keeping all advantages of requireJS.


Some examples, maybe?

I do not have a working module yet, as I’m still collecting feedback and ideas. I do however have some really simple uses for the view helper.

I do realize this illustrates the usage for your main module view, however it might give you a better idea of the structure I’m thinking about.


Any questions, tips or feedback?

Do tell me. This is just the theory and an initial proposal. So all feedback both positive and negative are well appreciated.


©SpoonX 2017