We’re a new startup with some venture backing. We’re looking to add an experienced developer to help us out for the next five weeks (and possibly more). Qualifications are:

• experienced PHP hacker (5+ years)
• full understanding of MVC frameworks (codeignitor, cake, symfony, zend, kohana or the like)
• comfortable with the LAMP stack
• understanding of git
• able to plug into a new project and start coding in under a day

You’ll be working with a team of 6 developers in downtown Burlington.

Kohort was featured in TechCrunch the other day for raising a “seed” round of $3 million. If you’re interested, contact Steve Blood. You can find Steve’s email address in this thread, or let me know and I can put you in touch with him.

Zend Framework is a free/open source web application framework. It can be used either as a component library or as a full-stack Model–View–Controller (MVC) framework. As compared to its 1.x counterparts, Zend Framework 2.0 is easier to learn, trivially simple to extend, and more performant. It is also easier to use just specific parts of the framework as needed. We will explore the many features of Zend Framework 2.0 including its tooling, functional testing, form, database, pagination, date, markup, navigation, and MVC components. Zend Framework 2.0 takes advantages of several new features in PHP 5.3 including closures/lambdas, namespaces, and late static binding. We will explore some of these new features to understand why PHP 5.3 is a requirement for Zend Framework 2.0 and how you can leverage these new features within your application itself. An example web application will be provided that you can use as a reference when building your own Zend Framework web application.

For those wondering, Zend Framework 2.0 is not out yet but SXSW is not until next March and Zend Framework 2.0 will most likely be released by then. The description above is based on the Zend Framework 2.0 Requirements and discussions on the Zend Framework contributors mailing list.

Model

Your domain objects. There is no Zend_Model since your domain logic is specific to your application. However, there are some best practices that have emerged in the Zend Framework community including Data Mappers (which I’ll talk about later).

See example Models in application/models/

View

The presentation layer. The default implementation uses PHP templates called view scripts. View script files have a default suffix of .phtml. There should be no domain logic in your view scripts. By default, there is one view script per controller action (we’ll see what that means shortly).

See example Views in application/views/

Controller

Connects the Model and the View. Each Controller contains one or more actions. The Controller’s job is to interpret input and pass it to the Model and also to provide Model data to the View.

See example Controllers in application/controllers/

By default, Zend Framework will route requests based on URI segments as follows:

:controller/:action[/:key/:value]

A few example URIs:

• foo/bar (foo controller, bar action)
• foo/bar/baz/shaz (foo controller, bar action, baz=shaz)

It is possible to customize this routing in pretty much any way conceivable but I’d suggest sticking with the default routing until you have a good handle on how it works.

In my next post in this series I plan on taking a slight detour so that we can explore a very useful component, Zend_Layout.