The Master Zend Framework site has posted a new tutorial showing you how to [use the ReflectionBasedAbstractFactory for prototyping](How To Do RAD Prototyping and Development With The ReflectionBasedAbstractFactory) and development in a Zend Framework 2 application.

Rapid application development isn't normally associated with Zend Framework. That's considered Laravel's domain. But thanks to the ReflectionBasedAbstractFactory, prototyping and rapid application development is now just as easy in Zend Framework as it is in Laravel. In today's tutorial, I'm going to show you how.

When using Zend ServiceManager, it's quite common to create a factory class for any class which require constructor dependencies. While tedious, it ensures we both follow development best practices and that the code we create is fully testable.

However, if we're not careful, it can lead to an enormous amount of factories — perhaps where we have one factory for every class. Needless to say, that can seriously hurt development. There needs to be a better way. And there is!

The ReflectionBasedAbstractFactory is included in the 3.2.0 release of Zend ServiceManager and makes use of the Reflection API to do some automagic, handy things. The article starts with some reasons why you might use it and a brief look at how it works. It also points out that, despite how it makes things easier on the developer it's "not for production" and instead relying on the other configuration handlers to help out.

In a new post to his site Alejandro Celaya shows you how to dispatch REST-like requests in Zend Expressive using a single-controller method.

I was digging into Zend Expressive and how to use controllers that allow me to share dependencies between different routes, instead of having to use different middlewares every time. Abdul wrote a great article on this subject that you can find here, which also became part of Expressive's cookbook some time later.

This is a perfect approach that easily allows to reuse some code, but then I thought how to do something similar in a rest environment, having a single class with different dispatchable methods that will be called depending on the request's HTTP method. This is a possible solution based on ZF2's AbstractRestfulController.

He starts by creating an AbstractRestController class to handle the basics of the REST handling, essentially matching verbs to their actions. He then extends this with a RestUserController class that overrides the necessary methods for only the HTTP verbs you want to change. He then shows how to register the route so it can be used by any request verb type (GET, POST, PUT, etc).

The Zend Framework blog has a post announcing the name change of the main Zend Framework repository on GitHub:

Per the GitHub documentation on renames, existing links will be automatically redirected, and will persist as long as we do not create a new repository with the name "zf2". Redirects occur for: issues, wikis, stars, followers and git operations.

The post also includes the instructions on how to update your current "remotes" in your git checkout (so you don't have to re-clone). It also mentions the change and how it relates to Composer - hint: nothing at all because of how Composer works.

An announcement has been made on the Zend Framework blog today about a massive repository rename that will be happening May 3rd, 2016 to move away from the "zf2" naming.

In contrast to Zend Framework 2, which was a complete rewrite and break with the architecture of Zend Framework 1, the Zend Framework 3 initiative is more of an evolutionary change. [...] Another way of putting it: changes to the main repository are happening incrementally, and version 3 will just be a new major version update within the existing repository. However, such evolutionary change poses a slight logistical problem: the repository is currently named "zf2".

In order to make the change to Zend Framework 3 (and beyond) simpler, the repository will be renamed to "zendframework" instead. In the current configurations this namespace already exists and points to the correct locations so, ideally, no changes will need to be made on the Composer installations of current users - just updates to git remote entries to point to the new locations.

On the Zend Framework blog there's an update from Gary Hockin about some GitHub project-level changes that will be happening soon. He'll be doing some housekeeping on the current list of open issues in the main zf2 repository.

I want to make you aware of some upcoming changes to the issues that are currently logged in GitHub. We currently have 426 open issues that are logged against the (now) meta zf2 repository. The vast majority of these are now in the wrong place, as we've split our once monolithic single repository into the many single component repositories. These issues should be moved from the zf2 repository to the correct component that the issue relates to.

He's closed some issues in preparation and tagged others with a "To Be Closed" tag for later handling. By early May all issues tagged "To Be Closed" will be finished out and/or moved to the correct locations. This will leave the project with around 100 issues to manage and to move to the right locations.

The Master Zend Framework site has posted the second part of their tutorial series showing how to test Zend Framework applications with CodeCeption, a tool allowing for behavior-driven testing methods on PHP applications. In part two of the series they finish up the examples from part one and put them to use.

In part one of this series on testing Zend Framework applications with Codeception, we covered what Codeception is, how to install and configure it, and how to enable and configure the Zend Framework 2 module; finishing up by writing some basic acceptance and functional tests. [...] Here, in part two of the series we see how to retrieve and test registered services using BDD-style testing. This isn't going to be an exhaustive look at every possibility of what's available. Instead, what I'm going to do is show a simple set of examples which use two extra modules which come with Codeception and how they enable descriptive, BDD-style, tests.

The tutorial starts by getting into a bit more detail on what BDD-style testing is and some of the basic terminology. They help you install two modules to help make writing your tests simpler. The tutorial walks you through generating a new test for a fictional "Video" table gateway class and how to flesh it out to pull the service from the service manager, configure the database connection and write a few checks to verify the type of the service fetched and the number of records it returns.

Alejandro Celaya has a post showing how he recommends working with sub-namespaced modules in a Zend Framework 2 application. It's based on a previous series of articles on the same topic but improves the methods for handling.

The solution provided in those articles was functional, but it introduced some new problems to deal with. It happens that after some time working with sub-namespaced modules I have found the best way to solve those new problems, and I wanted to write this new article explaining it.

He starts with the two main problems with the use of sub-namespaced modules: the autoloading of the module's files and how it resolves the locations of view scripts. Fortunately, the solution to both issues turns out to be "really easy". Composer's autoloading means that just changing the directory structure helps there and and update to the controller_map value helps with locating view files.

Rob Allen has posted another article about the ZendInput component of the Zend Framework (he talks about empty values here) this time covering the use of fallback values when the input doesn't contain the needed data.

Recently an issue was reported against ZendInputFilter where the reporter has discovered a regression where the fallback value wasn't being populated correctly. ?Matthew investigated, fixed it and asked me to review it. I was fascinated as I didn't realise (or had completely forgotten!) that ZendInput and ZendInputFilter supported fallback values so I looked into it and it turns out that it's simple and works exactly as its name implies.

He includes a simple example of a fallback for a name value set using the setFallback method on the Input object. He does point out one "wrinkle" in the functionality, however, dependent on the values set for required, allow_empty and continue_if_empty. Certain combinations could make the value either be returned differently than expected or not at all. He includes a small test script that shows the various combinations and what their expected output should look like.

Matthew Weier O'Phinney has a recent post about recent work that's been done to split up the componenents in Zend Framework 2 into their own repositories and linked as dependencies.

Today we accomplished one of the major goals towards Zend Framework 3: splitting the various components into their own repositories. This proved to be a huge challenge, due to the amount of history in our repository (the git repository has history going back to 2009, around the time ZF 1.8 was released!), and the goals we had for what component repositories should look like. This is the story of how we made it happen.

Matthew talks about the methods that were used to split things apart, even more so than they already were. While the components could be installed separately before, the methods used to get there were "cringeworthy". He talks about the different methods they've tried and the version bump issue that came with them, even when no changes were present. He talks about the ultimate goal of the refactor and the techniques to get there - a combination of grafts, subtree, subdirectory-filter and tree-filter through git. He covers some of the "stumbling blocks" they hit along the way including empty merge commits. The end result was a one-line command that could be executed and split out the provided component (well, with a lot of help behind the scenes).

He ends the post talking about the speed of the extraction process (hint: parallel processing is a happy thing), the ultimate results of the entire framework being split and a few lessons they learned along the way.

On the Osedea blog today there's a new post showing you a few ways you can speed up your Zend Framework 2 application with a few easy code changes.

After about a year developing a Zend Framework 2 application, we decided it was time to do some optimizations. Page load times were up to several seconds on our bigger pages, and none of our pages were loading in under 2 seconds. We took a few days to profile our application and scour the various ZF2 articles out there to see what could be done to reduce the load times. We found some pretty obvious causes as well as a few inconspicuous ones. Here’s a brief list of our findings, along with some steps on how to improve your ZF2 applications.

Their list includes updates around:

• Standard vs Classmap Autoloading
• Event Listeners
• Making your Module.php "skinny"
• Cache Settings
• Session Write Close

Each tip includes a bit of code showing what will need to be changed, making it easy to drop them in and make your application nice and speedy.