One set of features has really been helping me of late ones that really have me smiling; these are: Hydrators, Models and Table Gateways. If you're new to ZF2 or database interaction with frameworks, then you're in a perfect position as today's post will be giving you a good introduction to the basics of using both together.

He starts with a look back at how it all was done in ZF1 and shows how using these three components makes for an even better system, allowing the model to be completely data-source agnostic. His examples start with the table gateway class, showing how to connect it with a "users" table. From there he adds in the model (with an "exchangeArray" method) and a hydrator that maps the table columns to the properties on the entity. He shows how to add this setup to the service configuration and its use in a controller, returning a full list of the records in the "user" table.

This post shows the changes to the ZF2 tutorial application to allow it to run with Oracle Database 11gR2. [...] The instructions for creating the sample ZF2 application are here. Follow those steps as written, making the substitutions shown [in the rest of the post].

The full schema definition is included in the post, complete with the same sample data as the tutorial. He includes the updates you'll need to make to the database configuration for the OCI8 connection and changes to the code to accommodate the Oracle data format (mostly uppercasing everything).

For those that have used both frameworks, what one do you feel is a better overall framework? I tried ZF2 in beta and it seemed overly complicated to symfony but I don't know if its gotten better since then.

Opinions shared in the comments of the post include things like:

• "So if you are learning for job prospects, go Zend. I love Symfony 2 though, its a joy to work with."
• "It doesn't matter. Each has a strength and a weakness, and neither will go away. Pick one and use it, you'll be fine."
• "I don't think there is such thing as a best framework as you should use the best tool for the job. I don't think MVC is the solution to all problems."
• "Both are quite bloated but they have to be considering their target markets."

On the whole, the views are of the "best tool for the job" mentality - a good sign for the community and these two frameworks.

Today using Zend Framework 2 RouteMatch, Router and Request objects, I show you an easy way to dynamically update the current route. It's almost painlessly simple. [...] Well, like most things in web application development, what starts out simply in the beginner often grows more complex over time. So too is my once simple route.

His "simple" route started getting a bit out of control when he added in some pagination to the page (and query for the path match). He wanted to figure out how to re-render data with the same filters but show the next page of data. He shows how to use the RouteMatch component to achieve just this. He creates a custom module with a "listViewToolbar" helper that lets you read the router, request and handle the parameters sent via the URL. The "invoke" method is called to render the toolbar in the page, complete with the new settings.

One thing you may find yourself needing to do is access configuration information in a controller or service class. The easiest way to do this is to use the ServiceManger's initialiser feature. This allows you to write one piece of injection code that can be applied to multiple objects. It's easier to show this in action!

He includes a sample configuration file (with a setting for "setting_1") and the interface you implement to structure the load request. He then shows how to hook this into the controller and the code needed for the module "getControllerConfig" (or "getServiceConfig" for use with services) to load in the file and set it to the correct object.

Both ZF2 and Symfony 2 offer the same behavior: if I'm in a controller, and I want to use a service, I have to get it from the container with $this->get('my_service'). As such, the controller is not using DI, this is the service locator pattern. Controllers become more difficult to tests because of that, and they depend on the container now. I wonder why both frameworks didn't go further: why not treat controllers like services and use dependency injection on them. In other words: if a controller needs a service "A", then it should get it in the constructor, or through setter/property injection.

The comments talk some about the "controller from the DI container" idea, some other ways around the problem and some clarification as to what the frameworks are actually doing related to the container injection.

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

In this post, I'll be covering documenting your API -- techniques you can use to indicate what HTTP operations are allowed, as well as convey the full documentation on what endpoints are available, what they accept, and what you can expect them to return. [...] hy Document? If you're asking this question, you've either never consumed software, or your software is perfect and self-documenting. I frankly don't believe either one.

He covers a few reasons why you should document your API and where he thinks it should live to be the most useful. He includes a few different ideas and two things he definitely thinks should exist for your API - the use of OPTIONS and end-user documentation. The first is a HTTP header (ZF2 code example included) that tells the API consumer what they can do with an endpoint. The second type is more useful for the human reader, giving them a better overall perspective on what the API can do - still served through the API but in a bit more understandable format.

In this article I detail the process by which you can set up your controller actions in Zend Framework 2 to return either the default HTML, or JSON data depending on the "Accept Header" in the request. It incorporates changes related to a security update added since this very helpful article was written, and expands on some of the intricacies of making your web layer objects better "json providers."

His example uses a "ViewJsonStrategy" and the criteria to look for to determine which version to respond with (HTML or JSON) - the Accept header. It uses the JSON encoder/decoder instead of the built-in PHP one to he could use the included "toJson" method to customize the output of the JSON instead of just returning everything.

In my last post, I covered some background on REST and the Richardson Maturity Model, and some emerging standards around hypermedia APIs in JSON; in particular, I outlined aspects of Hypermedia Application Language (HAL), and how it can be used to define a generic structure for JSON resources. In this post, I cover an aspect of RESTful APIs that's often overlooked: reporting problems.

He starts with some of the things around error handling and APIs that bother him and why just returning a status code representing an error isn't enough. He suggests two possible solutions to this issue - two messaging formats, API-Problem and vnd.error. He gives brief summaries of each and includes example output to give them some context.