PHPMaster.com has posted the second part of their look at the Openbiz Cubi framework (part one here), this time focusing on the code - mostly XML - that you'll need to create your own custom module.

In the first part of this series we talked about the development challenges we face and how Openbiz Cubi can help by providing a solid, ready-to-use web application framework. In this part we'll see how to build our own module and dive a bit deeper into the core architecture of the framework.

They include the SQL you'll need to run to create a new table for the "Customer" module they're going to help you build. With that in place, they walk you through the command to execute to make the module skeleton, the locations of the XML files to work with and the contents of each. Included in the module are things like a data object, a module description file and the form object. He finishes up the post with a look at the overall flow of the Cubi execution so you know where each piece falls.

Matt Setter has a new post to his site today about forms in Zend Framework 2 including a full example on how to use them to create a form for user information (first name, last name).

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).

Rob Allen, in his Zend Framework 2 development, has come up with a list of suggestions about the use of modules in your applications, mainly relating to the structure of the files inside of them.

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.

Matthew Setter has a new post to his site today introducing you to modules in Zend Framework v2 - the "application's heart".

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.

On PHPMaster.com today there's a new post (by Remi Woler) that looks at abstraction and keeping functionality out of the framework and more decoupled in case the need for switching environments/frameworks comes up.

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.

Rob Allen has posted a technique for integrating the BjyAuthorize, a helpful module for access control in your Zend Framework 2 application, with the ZendNavigation module for user permissions-based navigation updates.

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.

Martin Shwalbe has a new post that wants to help you get started using the Zend Framework 2 for creating REST web services quickly and easily.

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.

Rob Allen has a new post to his site sharing some examples of the configuration possibilities for the ZendServiceManager module of the Zend Framework 2.

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.

Rob Allen has a new post to his site about module-specific layouts in Zend Framework 2 via a module from Evan Coury.

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.

In his most recent post Nikita Popov asks if PHP developers are functophobic - that, in some of his experience, they don't like to use functions.

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.