On the Laravel News site there's a quick tutorial posted showing you how to use named routes in Lumen in writing tests for your application.

When writing tests in Lumen, I recently discovered that the route() helper doesn’t work with tests out-of-the-box.

I prefer to define named routes and make requests against them in my tests. If you follow the Lumen documentation, the typical way that you make a request for a test [of the return of a JSON endpoint results in an error message]. [...] If you inspect things a little closer, you can see the issue: [...] Interestingly, the route doesn’t look quite right, and the router is returning the / route. It looks like the localhost part of the request isn’t being set, and the route isn’t matching. We can fix that by bootstrapping the request as Laravel does.

The post then walks you through the manual process of bootstrapping things so that routes are correctly resolved. This includes changes to the code for the base test case to handle the "boot" and set the path value for the request correctly.

In a post to his site Philip Brown shows a helpful way to manage API exceptions in a Laravel-based API application. In an API, exceptions are particularly important as they can be a hint to what the problem is and make it easier to return the correct error code to the client.

Exceptions are a very important method for controlling the execution flow of an application. When an application request diverges from the happy path, it’s often important that you halt execution immediately and take another course of action.

In today’s tutorial I’m going to show you how I structure my Laravel API applications to use Exceptions. This structure will make it very easy to return detailed and descriptive error responses from your API, as well as make testing your code a lot easier.

He starts with a brief introduction to HTTP status codes and their role in the interaction between client and server. He then gets into the "exception foundation" and how it will work, providing some basic common functionality (like throwing a 404 when a record isn't found, regardless of the type). He creates a configuration file to define the default error messages, an abstract Exception the custom instances can extend. He creates several of these as an example, such as a "UserNotFound" exception that extends the base "NotFound" exception class. He works with Laravel's own exception handlers and includes the code to catch a few different types inside.

In this new post to his blog Till Klampaeckel shares a Zend Framework "base" controller that makes it easier to do the usual CRUD (Create, Read, Update, Delete) operations in an application.

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.

Richard Miller has a new post to his blog today that recommends moving away from the base controller the Symfony introductory documentation has you make. He suggests an alternative that can be used more widely.

In fact, it is the advised best practice for controllers in shared bundles. When you do, you will no longer have access to these useful methods, in this post I am going to look at how to accomplish the same tasks without them. I have created a simple controller for some basic form interaction with a model which uses the base controllers methods. I am going to go through how to change this to a service which does not extend the base controller.

He starts with his "TestimonialController" that does some of the basic CRUD operations on the testimonial information. He shows you, step-by-step, the refactoring needed to stop using things like the default controller helpers (each with replacement code). With those removed, he can move to extend "ContainerAware" instead of "Controller", make the controller a service and doing some dependency injection for needed resources.

Following in the heels of his first post looking at a few of the templating offerings available to PHP applications, Gonzalo Ayuso is back with part two - a comparison versus just "plain PHP".

In my last post I created a small (and very personal) test of different templating engines in PHP (Smarty, Haanga and Twiw). Someone posted a comment asking for the comparison between those template engines and old school phtml. OK I’ve done some tests. It’s a bit difficult to create the template inheritance (without cloning one of the template engines and creating a new one) so I have one approximation with a simple include. It’s not the same but it’s similar.

He tries to recreate a similar scenario as in the three other templating tools by setting up a base template (with inline PHP), a class to populate the contents of it and a sample template with "inheritance". He stacks up the execution times and memory usage against the results from the other three with interesting results, specifically compared to Haanga.

In a new post to his blog Phil Sturgeon looks at creating sharable code for your controllers in a CodeIgniter application (DRY: Don't Repeat Yourself).

The idea is that most of your controllers share something in common with each other. For example: All admin controllers need to make sure a logged in user is present and that they are an administrator. A public controller may want to load a theme for your application and load default user data, navigation links or anything else frontend related.

The problem is solved by creating a base controller - in his example its one called MY_Controller that follows the CodeIgniter naming convention and allows you to easily make other controllers that extend it. You'll also need to make a small addition to your config.php file to get the base controllers working correctly and make them able to be found.

Ben Scholzen has written up a post about how regular PHP arrays can be used as a native configuration option for your applications.

I was asked many times how I organize my config files, and my response was always the same, until some time ago when I switched began refactoring the codebase of my blog. [...] Looking at [the advantages of PHP config files], you may ask now why not everbody is using them. Well the problem mostly is that you cannot create extend-sections (when working with Zend_Config for example).

He compares an example of a method that, using a base config file with some "smarts", you can have it automatically pull in certain files and overwrite settings from the array inside. A sample "other config" file is also included, showing the definition of some PHP settings, resources and database information.

In this recent post Jordi Boggiano looks at a different sort of design pattern - a sort of extension of the Singleton pattern: Multition.

While I like the Singleton pattern every now and then, I prefer the flexibility that the Multiton potentially offers, and well it's just an extended version of the Singleton, so it's "compatible" with the Singleton model. Anyway, to the point, PHP5.3 is coming, and with Late Static Binding you can do a base Multiton (or Singleton if you insist), which wasn't possible before. Now I like this very much because you can simply extend it rather than rewriting those (few, I know, but still) lines each time.

Included in the post is an example of the design pattern showing how to create its structure in the class and use it to grab the same or unique instances (defined with an ID).

Jani Hartikainen has followed up on a post from David Otten about standard classes in PHP and how they provide the base for much of what the language does.

David Otton posted a short but thought-provoking post about stdClass, which many think is the “base class” all PHP classes automatically inherit from. I have to admit that I had this misconception as well. [...] This [difference in PHP from other OOP languages] presents some room for analysis in how things are handled in dynamic and static languages, and how those differences affect things...

Jani talks about dynamic and static typing in languages and how that effects the base types things are extended from as well as some of the benefits that having a standard base class affords developers.

In a quick new entry to his blog, Richard Thomas shows how to integrate the popular jQuery javascript library into your Solar application.

Going to go through a quick walk through of how to use a hacked together version of my old jquery library with solar. You can find the class source files here.

He sets up a callback in the Base controller (that all other controllers extend) for the jQuery calls so that any of the "child" controllers can just call "/controller/jquery" to make jQuery requests.