I think it goes without saying, forms are one of the central elements of any web-based application. They're used for everything from logging in, to searching content and managing information. Given that, they should be first-class citizens, able to be developed and reused with relative ease. [...] However, given the amount of options, configurability and flexibility required, this isn't always easy. [...] In today's post, I'm going to assume you have a basic understanding of how forms work now. [...] I'm going to show you how to create flexible, reusable forms in one module and by the power of the ServiceManager reuse them throughout your application.

He starts with the inclusion of a dependency needed for his example - the ZfcUser component (installed via Composer). He then moves on to the actual code for the form creating a reusable module, an entity class for the User and the Fieldset/Form classes for the contents of the form. He also includes the code for the controller action and the view that outputs the form itself and handles the repopulation automagically (and includes a CSRF token).

I've been working on a Zend Framework 2 module within a larger project that doesn't have that many PHP class files. Specifically, it has a controller, a mapper, an entity, a service and a form. As a result, the traditional Zend Framework 2 directory structure for the Account module looks [overly complicated]. That's a lot of directories for not many files! As a result, I decided to flatten it to [something simpler].

He includes both the "before" and "after" directory structures and continues on with two more suggestions - the removal of the top level "Account" folder inside of "src/" and, finally, removing "src/" all together with a slight modification to the autoloading. With a simpler module, though, something like this might make it easier to maintain and "follow" later down the road.

So it really is rewarding and exciting to begin covering all that it has to offer us. In part one of this series, I looked at a central concept of the revised framework - Dependency Injection. In this, the second part, I'm moving on to give a good introduction to the next most important aspect - Modules. In today's post, we'll be looking at what they are, some thoughts and quotes from the key developers involved and working code to get you started.

He talks about some of the key parts of modules in ZF2 (autoloader, manager and listeners) and includes links to a few examples. He then walks you through the creation of a simple module, scaffolding out the basics of the config and autoload handling. He leaves the rest up to you though including adding in the controller/model/views for the module and unit test or language support.

Of course you develop using the latest technologies and frameworks. You've written 2.5 frameworks yourself, your code is PSR-2 compliant, fully unit-tested, has an accompanying PHPMD and PHPCS config, and may even ship with proper documentation (really, that exists!). When a new version of your favorite framework is released, you've already used it in your own toy project and submitted a couple of bug reports, maybe even accompanied with a unit test to prove the bug and a patch that fixes it. If that describes you, or at least the developer you want to be: reconsider the relationship your code has with the framework.

He talks some about the dependencies most code written today has on the frameworks it lives in and how a good project design can make it easier to decouple this relationship. He suggests using things like wrapper classes (think "services") to abstract out the functionality to custom components. It's these components that handle the work, just reporting back the results to the controller/model that called them.

If you are using BjyAuthorize for ACL configuration and want to use ZendNavigation's ZendAcl integration features, then you need to set the Acl and Role information into ZendNavigation.

He includes the code you'll need to add to both the bootstrap of your application and the configuration to set up the "rule_providers" and "resource_providers". Then you can update your navigation settings to include "resource" and "rule" options to define with options a user can see.

Today i want to show you how to build a rest application. This tutorials assume you have completed the Getting Started. I will be repeating lot of the steps allready explained in there. There is also a sample Album module which you can install from here.

He starts off by setting up the Album module to load via the module autoloader and sets up its controllers and views in the module configuration. He shows how set up the REST routes (via the "router" in the module config), how to set up the view strategy and how to make a first controller. There's also a bit about testing this newly setup module with PHPUnit.

ZendServiceManager is usually configured in two places: an array in a config file or a method within your Module class. In either case, you provide a nested array of configuration information. [...] Within the service_manager array, there are a set of nested arrays which are generally used to configure how you want a given class to be instantiated. the names of these sub-arrays are hardcoded, so you just need to learn their names and the difference between them.

He lists out each of the options and includes a brief example and description for each. Values include "invokables", "aliases" and "initializers". He also touches on controllers, view helpers and controller plugins and how they hook into the ServiceManager.

If you need different layout scripts to be rendered for different modules in Zend Framework 2, then Evan Coury has made this extremely easy. His new module EdpModuleLayouts is just the ticket! Once installed, you simply have to add a new array to a config file in the config/autoload folder.

The update is just a simple "module_layouts" setting that lets you specify it based on the module name by giving it a layout path, He explains the script a bit more in the comments and points to this other post for more information about modules handling their own layouts.

Now, that was overly general, so let me clarify: PHP developers who have reached a certain degree of sophistication basically stop using plain functions - instead everything goes all classes and methods. At least that's the observation I made when looking at various open-source libraries and frameworks. The only type of function you'll find in any of the "high-quality" libs are anonymous functions. But that's pretty much it.

He shares concern that this "anti-function" approach can cause some bad practices to come up, specifically when developers try to force things into OOP that don't need to be there. He suggests that "helper functions" are a perfect example of individual functions that might not need to go in a class. He notes that, unlike in other languages (like Python), PHP development tends to follow the "one class, one file" route. He wonders if a shift from this method and more to a "module" approach (a more "compact" method) could be a good thing.

The release of the first RC (release candidate) of Zend Framework 2 is getting close. One last beta (beta5) and then the RC will be announced! With the current pace of modules spawning on GitHub, I think it is a good idea to give some insights in how you can use 3rd party modules. In this blog post I will focus on MVC modules: modules with routes pointing to controllers and view scripts for rendering. Because using a 3rd party MVC module does not mean you are enforced to follow their routing scheme, use their view scripts or use the predefined forms, I will explain how you can modify those options to your needs.

He covers the three steps needed for integration - adding a new route to handle the requests to the module, adding a view script to handle its output and working with a Form instance to add a bit more handling.