NetTuts.com has posted a new article for the Laravel users out there - a tutorial showing how to test Laravel controllers via PHPUnit tests.

Testing controllers isn't the easiest thing in the world. Well, let me rephrase that: testing them is a cinch; what's difficult, at least at first, is determining what to test. Should a controller test verify text on the page? Should it touch the database? Should it ensure that variables exist in the view? If this is your first hay-ride, these things can be confusing! Let me help.

They break up the testing process into three main chunks - isolation of the tests (mocking where need be), calling the controller method and running the checks (assertions) to be sure the result is valid. They start with a basic controller test that runs a GET request on the "posts" method. They also mention the assertion helper methods included with Laravel controller testing, things like "assertRedirectedTo" and "assertSessionHas". The article then gets into moreo practical examples showing a TDD approach to testing some simple controller calls, mocking data connections, handling redirects and repositories.

In a previous post of his Dave Marshall talked about using controllers as "services" in a Silex-based application. In this new post he takes it a step further and shows you how to use route helpers to make working with those controllers even simpler.

Supposing we want to render some HTML, do we want to inject the template engine in to the controller? Should the controller be responsible for knowing how to render the template? I'm not sure, but if I can have it not do it with minimal fuss, I think I'd rather it not. The full stack framework has the @Template annotation, which allows developers to assign a template to a controller and then simply return an array. If they can do it in the full stack framework, we can do it in Silex.

He includes the code for an example of a 404 handling page that uses the "convert" method to configure a route (path to a controller) for the currently matched route. He also shows the creation of a simple "CustomRoute" class and a "TemplateRenderingListener" to make it simpler to customize the handling and output of the request, all injected into the application's DI for later use.

In his latest post Robert Basic looks at working with custom view helpers in your Zend Framework 2 application and shows how to implement a simple one to display a simple greeting.

I took the skeleton [Zend Framework 2] application, made it even skinnier by throwing out some (for me) unneeded parts and just put it all besides my old ZF1 code. [...] The first problem I ran into was using custom view helpers, especially view helpers that are more general and don't fit into one specific module. Where to put the code? How to access them in views? The second problem was how to access the service manager from a view helper? And the third problem was how to tell the helper to use a specific value when inside a specific module?

He includes a simple example - the greeting helper - and shows where to place it in the application structure, how to work with the service locator inside it and how to set up some module-specific views inside.

Evan Coury has a new post today showing how to create a simple view helper in a Zend Framework 2 based application.

This post will show you how to create a simple view helper in Zend Framework 2. In this example, our view helper will simply return the full, absolute URL of the current page/request.

Code for the example is included, showing how to pull in the namespaced dependencies and extend the AbstractHelper to define the simple view helper. The "__invoke" method is used to handle the functionality and the configuration for the helper is defined in the Module's "getViewHelperConfig" options. You can find out more about the View Helpers in Zend Framework 2 in their manual page.

In this recent post to his site, Matt Cockayne shows you how to bootstrap your forms in a Zend Framework 2 application (as defined in a class).

A brand spanking new Forms component has been rolled out with ZF2. The long and the short of this new component meant that I had the opportunity to hand roll a new way of making my forms work with Twitter Bootstrap. So, a little tinkering, a quick pull request to ZF2 to allow the definition of arbitrary options and I came up with some useful View Helpers that can be dropped into a project and used.

He includes the code for the sample class ("MyForm") and highlights the "bootstrap" portions of each element's configuration and walks you through some other handy features of his helpers: auto-rendering forms, a "row" helper and a "collection" helper to help organize the form structure.

The Code2Learn site has posted another in their CodeIgniter "series" about producing various kinds of output from an application based on this framework. In this new article Farhan Khwaja shows how to output a CSV-formatted file.

I have already written posts on how to generate pdf files using CodeIgniter Framework and also on how to generate tabulated pdf file using CodeIgniter Framework. This post will help you to generate a CSV file using CodeIgniter. The data for the CSV File will be taken from the MySQL Database and will be put into the CSV File.

He includes the source for a basic "Generate" controller class that uses a custom "CSV_Helper" to do the work. It has two methods - one to transform array data and another to take the database result object and extract each record.

On the Code2Learn blog there's a recent tutorial about creating PDFs from CodeIgniter using the R&OS PDF class (not bundled with the framework, but easy to integrate).

As a programmer I find PDF files very helpful to me when generating reports and getting them printed. We will be using R&OS pdf class. I find this to be the best one because all others libraries I came across didn't offer me a good control over the making of the file and also the process of making i.e the code required for this library is bit tricky but it helped me improve my coding.

Code is included to create a simple PDF helper class that creates a new "cezpdf" object and add some basic things like titles, page numbers and some basic footer text. A simple controller is included that pulls the information from a database table (in their case a record of logins) and pushes this data into the PDF as lines of text.

In the second part of their look at using closures in PHP as view helpers, DevShed improves upon their original code by adding some additional classes and using them in the closures.

The best way to show you how using anonymous functions can help you to develop more efficient OO applications is with some functional, hands-on examples. With this idea in mind, in the installment that preceded this one, I implemented an extendable template system. This system could spawn view objects and render the template files associated with these objects.

In this second part of the (two-part) series they include "Serializer" and "FileHandler" classes and show how to use them inside of the closures to lazy-load in data from an external file and work with it as serialized content.

Nicolas Grekas has shared another tool that he's pulled out of his "Patchwork" framework to make it a stand-alone tool: the Patchwork-UTF8 helper that provides matching functions to those PHP already has for regular strings, but a little smarter to work with UTF8 correctly.

The PatchworkUtf8 class implements the quasi complete set of string functions that need UTF-8 grapheme clusters awareness. These functions are all static methods of the PatchworkUtf8 class. The best way to use them is to add a use PatchworkUtf8 as u; at the beginning of your files, then when UTF-8 awareness is required, prefix by u:: when calling them.

In the README for the tool he talks about the functions included in the current release that match PHP's string functions as well as some additional methods like "isUtf8", "bestFit" and "strtocasefold". It relies on the mbstring, iconv and intl extensions being installed, and if they aren't, it falls back to other functionality (list of those methods included).

New on DevShed today there's a tutorial looking at using one of the newer features of PHP, closures, as view helpers in a basic templating system.

In this two-part tutorial I'll be showing you, in a step-by-step fashion, how to use the goodies offered by closures in the implementation of an object-based, easily extendable template system. This system will allow you to embed anonymous functions easily into template files, and call them as typical view helpers, too.

He starts the process of creating the templating system by defining two interfaces, the View and DataHandler. Using these as a base, he creates an instance of the ViewInterface (a "View" class) that can set the template file to use, set values to be displayed and render the formatted output. Included is a basic template and how to use the View class to set values into it. The "render" method is called on the view and the HTML markup is produced. The closure comes in when they try to call a value "clientIp" that needs to do something more complicated than just having a string assigned to it.