Very useful. Thanks Florian!

Let’s face it, nobody likes a dirty fork. In this series, I’ll show you some of the tricks I’ve learned over the years to successfully maintain a clean fork on GitHub for projects I actively contribute to.

The first article covers creating your clone, adding remotes, keeping things up to date and working in topic branches. It’s definitely worth a read and I’m looking forward to the subsequent articles in the series.

Matthew Weir O’Phinney has announced that contributors to Zend Framework 2 do not need to have signed Zend’s Contributor License Agreement from now on. Zend Framework 2 is developed using git and there’s a mirror on github, this means that contribution to ZF2 is now just a pull request away!

I especially liked point 4:

Ask a complete question, directed to anyone willing to answer (that is: don’t direct it to any person or group in particular). If someone knows and has time, they will respond. Why rule out people in advance, without even telling what your question is?

Also, I can only echo the comment about being patient in point 7!

Read the whole thing though and you’ll find that you get your answers from IRC with much less pain.

For a framework (and maybe for other software), I think the following rules are necessary in order for a rapid release cycle to work:

• Minimize backwards compatibility changes between major releases. Targeted and strategic refactoring, rather than major overhauls, are preferable if you are releasing often. Small backwards compatibility changes makes migrating from one major version to another much easier.
• Mark some major releases as “Long Term Support” (LTS) releases. Provide bug fix updates and security patches to these releases for three to five years. This provides a “safe” option to those who value stability and don’t want to upgrade very often. In the context of Zend Framework, it is obviously Zend’s decision if they want to take on this burden. If not, then I don’t think a rapid release cycle is viable.

What are the concerns with a rapid release cycle? I’ll paraphrase, and then address, the major concerns that I’ve heard.

Well worth a read.

Thanks to a discussion on the Zend Framework mailing list I learned about a new feature, a feature that allows for grouping action controllers in subdirectories!

He then goes on to explain how he can now group controllers related to admin within a subdirectory of controllers which makes organisation easier:

Best part is that this feature requires no additional configuration. Create a subdirectory under the controllers directory and place the controller file under that subdirectory. In that pretty screenshot image you can see a FooController.php in the directory called Sub; the class name in that example is Sub_FooController and is accessible via the sub_foo/controller URI. The corresponding view files should be placed in views/scripts/sub/foo/ directory.

For www.nd.nl (a Dutch newspaper) we wanted a simple and free queue mechanism that integrates with Zend Framework for handling a number of jobs. We found MemcacheQ.

The article then goes through how to run the memcacheq daemon and then shows the PHP code to add a job to the queue and then how to retrieve them elsewhere and process them.

HTML4 had a few different input elements that could be added to your form : text, password, hidden, checkboxes etc. HTML5 brings even more types that can be added to your <input> tag.

He then goes on to provide a override to Zend_Form_Element_Text showing how to use the new attributes with Zend_Form.

Basically, I’ve created a single class that effectively take the place of Zend_Db_Table_Row::findManyToManyRowset() for the purposes of creating an iterable rowset that allows access to both the target many-to-many rowset as well as the junction rowset. This solution is called a Composite Rowset. In this solution, both rowsets (iterators) are kept in sync with one another. This proves to be an ideal solution in a couple of ways. First, it will produce consistent row objects that are explicitly tied to a row in a database. Second, the cost of creating this composite rowset is at the expense of 2 queries: the original many-to-many query and a similar query to retrieve the junction rowset. This is ideal since previously, to get the junction data, findDependentRowset() would have had to been called on each row within the rowset produced by the Zend_Db_Table_Row::findManyToManyRowset().

He then goes on to show the API for the Composite Rowset class and provides an example of usage.

If you’re using Zend_Db_Table at all, have a read.

My favourite text in the article is however this:

Over the past several years of working on Zend Framework, I’ve noticed the developer population at large is really good at finding undocumented and previously unthought-of use-cases of Zend Framework components. These use-cases, while sometimes “inventive” to say the least- are also sometimes blatant misuses of a component.

That’s one of the pleasures of providing code to the world

I had a twitter/IRC exchange yesterday with Andries Seutens and Nick Belhomme regarding applications that include widgets within their layout. During the exchange, I told Andriess not to use the action() view helper, and both Andriess and Nick then asked how to implement widgets if they shouldn’t use that helper. While I ended up having an IRC exchange with Nick to give him a general idea on how to accomplish the task, I decided a longer writeup was in order.

He then goes on to explain how to create a module that does not have controllers and actions, but instead uses an action helper to create a widget that allows a user to log in.