I think it took me (or us) a couple attempts to get this right - let me introduce you to Zf_Crud, a CRUD controller for the Zend Framework. [...] Zf_Crud aims to provide you with an interface for any table possible - think of it as a phpMyAdmin more tailored towards your data and (thanks to Twitter Bootstrap and the Easybib_Form_Decorator) prettier!

He shows how to install and use it (via PEAR or Composer) and an example of a controller extending it. You can find the code here on github, ready to clone and try out.

The last article was about how to create call flow nodes for asterisk, using pagi and php, to easily create telephony applications. It's now time to add a layer on top of it, and create a complete call flow with several nodes.

He talks about NodeControllers to control execution flow, results from their execution, available actions and an example of creating a controller and adding nodes. He builds on this simple controller and shows how to handle a few actions including responding to user feedback, adding multiple menu options and some more complex logic using a closure to contain the functionality.

There's really no such thing as "module-specific" anything in ZF2, so what we're really talking about is the topmost namespace of the controller being dispatched. So in the case of MyModuleControllerSomeController, the topmost namespace would be MyModle. In most cases, this will be the name of a given module.

He gives a quick piece of sample code showing a "Module" class that attaches an event on the dispatch of its request. Inside this event, he grabs the controller (target) and updates the layout via a call to the "layout" method. This is all handled in the "init" method of the module, so it should "just work" when the module is used.

In the first article of his series, David explained how REST is more than an architectural pattern. It's a set of guiding principles that, if followed, can help you write scalable and robust applications. In the following articles, David will resume the discussion by looking at REST from the client-side of the equation. In this article though I'd like to focus on the server-side. You'll learn how to shift your thinking from the action-focused mindset that's prevalent in web development today to a more RESTful, resource oriented, approach, and see one way to structure your code and route URI requests in PHP.

He talks about the change in mindset it takes to create an effective, resource-focused RESTful service and shows some of the initial steps towards getting it all down in code (based on a simplified "front controller" that routes the request appropriately). The resources are defined as classes (like the "Restaurant" in their example) which then handles the type of request based on the request type (GET, POST, etc).

The new view layer in Zend Framework 2 can be set up to return JSON rather than rendered HTML relatively easily. [...] Firstly we need to set up the view's JsonStrategy to check to a situation when returning JSON is required and then to render out JSON for us.

This "JsonStrategy" does some of the hard work for you - detecting when the client is requesting a JSON response and looking at the data coming into the view to see if it's JSON. He shows how to implement it in a sample module using the "onBootstrap" module and how to force a return of the JsonModel even when JSON isn't requested (useful for a consistent interface).

This is the second part of a series, showing how you might write a RESTful API using PHP. This part covers the routing, autoloading, and controller code for the service, and follows on from the first installment which showed how to parse the incoming request to get all the information you need.

She shows how to grab the controller name from the incoming request (based on her previous code), create the object for it and execute the requested action name. Also included is a sample autoloader and a basic controller - a UsersController with "getAction" and "postAction" methods for responding to GET and POST requests.

Just wrapped up a call working on our webinar schedule for the year. We've got a bunch of ideas but we'd like to also get your input as well. Yes, I know y'all want ZF2 webinars. We have that down. I would also like to do an HTML5 and mobile webinar but I need an SME (Subject Matter Expert) for that. [...] I would also love to have webinars on how to use various API's, even if there is not native PHP support. So, what kinds of webinars do you want?

Leave your suggestions in his comments along with one already suggesting a "Why PHP?" checklist of sorts to help encourage companies/employers to go with the language.

In this edition, I talked with Enrico Zimuel a computer geek since he was 9yrs old. He has written a couple of books namely "Secrets, Spies and Cipher Codes" published by Apogeo in 1999 and the recent "How to use the digital sign" published by Tecniche Nuove in 2010. Enrico has a pretty impressive 'geek' path. He also speaks at many international conferences [...]. You can find his presentations on slideshare.

Questions in the interview include:

• How do you find PHP now as compared to when you first started?
• Based on your experience, what are the good and bad parts of PHP?
• To someone who wants to become a better PHP developer, what is your advice?
• What are some good PHP blog or resources you highly recommend?

Read the full interview here.

The move is pretty straightforward and makes a lot of sense as soon as you create more pages but you might have noticed a non-desirable side-effect... The LeapYearController class is always instantiated, even if the requested URL does not match the leap_year route. This is bad for one main reason: performance wise, all controllers for all routes must now be instantiated for every request. It would be better if controllers were lazy-loaded so that only the controller associated with the matched route is instantiated.

To help solve the issue, he uses the HttpKernel component and its "controller resolver" to figure out how to call the controller and pass it the correct parameters, but only when needed. A resolver object is created and that is used to instantiate the controller object. Sample "action" calls are included to fill out the basic controller (his "leap year" example) and the full resulting code is included both for the framework and the new object oriented controller.

Web applications usually follow a synchronous communication model. However, non-interactive and long-running tasks (such as report generation) are better suited for asynchronous execution. One way to off-load tasks to run at a later time, or even on a different server, is use the Job Queue module available as a part of Zend Server 5 (though not as part of the Community Edition). Job Queue allows job scheduling based on time, priority, and even dependencies

In his two examples, he shows the code involved to create a new Queue object and define a HttpJob in it. The first just calls a "sample.php" script that's exposed as a part of your external-facing site and shows how you can get the current status of the job. The more advanced example shows a call to a "report.php" script with a set of options defining things like "type", "length" and "priority". He also points out some other options that can do similar things like Gearman, NodeJs and RabbitMQ.