On NetTuts.com today there's a new tutorial posted about "taming" Slim 2.0, the latest version of the popular PHP microframework. They look at application structure and share some tips to using this update.

Slim is a lightweight framework that packs a lot of punch for its tiny footprint. It has an incredible routing system, and offers a solid base to work from without getting in your way. Let me show you! But that's not to say that Slim doesn't has some issues; it's one-file setup becomes cluttered as your application grows. In this article, we'll review how to structure a Slim application to not only sustain, but improve its functionality and keep things neat and systematic.

He starts with an example of "vanilla Slim" and looks some at what's happening behind the scenes in the routing engine. They then give you a step by step installation and usage guide including updating the router to use class files. An example controller is included as well as some basic error handling using a Twig template for use across the application.

On his site Fabien Potencier has posted about a feature added to Silex to help make debugging the flow of your application "more fun" - the Symfony web profiler.

One of the big advantages of both Symfony and Silex is that they are based on the Symfony HttpKernel component. [...] But handling HTTP requests with the Symfony HttpKernel also gives you a lot of free and optional features like a built-in reverse proxy written in PHP, easy handling of ESI and Hincludes (via the Fragment sub-framework), or the gorgeous Symfony web profiler.

The profiler provides information on which components were accessed, their memory consumption and how long they took to execute. The integration happens via the WebProfiler provider for Silex and is already integrated into the Silex skeleton base application.

Vance Lucas has a new post to his site sharing at a project he's been working on, a micro-framework for PHP that takes a functional approach to its structure (and the structure of the apps you can make with it), Bullet.

Bullet is a new PHP micro-framework with a unique functional approach to URL routing that allows for more flexibility and requires less verbosity than the more typical full route+callback approach found in other micro-frameworks. The main problem with most micro-frameworks and even full-stack MVC frameworks that leads to code duplication is that the callback or method executed to perform the action and respond to the URL route lives fully within its own scope. This means that you are forced to repeat a lot of setup code across URL route handlers that load the same resource, authorize it, etc.

He illustrates with an example of a GET/DELETE to the same routes and having to create multiple handlers for each. He restructures this with Bullet and shows how it can nest callbacks inside of handlers to make for simpler routing. It also scopes down requests and gets more fine grained as you nest, making it easier to create reusable handlers (like in other files). If you're interested in finding out more about Bullet and its structure, you can find it in the project's main site.

On the IBM developerWorks site there's a new tutorial posted walking you through the process of creating a REST application with Slim, a popular microframework for PHP.

In this article, I introduce you to Slim, a PHP micro-framework that's designed for rapid development of web applications and APIs. Don't be fooled by the name: Slim comes with a sophisticated URL router and support for page templates, flash messages, encrypted cookies, and middleware. It's also extremely easy to understand and use, and it comes with great documentation and an enthusiastic developer community.

They start off by defining REST in terms of its usual four "verbs" - GET, POST, PUT and DELETE - and the conventions of the types of actions for each. Once you get the framework installed (via Composer) they help you create a sample database with an "articles" table and some sample data your service will work with. They go through each of the "verbs" and include code showing how to respond to the requests for each, including some exceptions for when things go wrong. There's also a bit about adding authentication "middleware" to the process - a hook to validate a user key as a part of the routing process. They finish things off by showing how to support multiple response formats and like XML and JSON based on the requested media type.

With all of the recent talk about the Aura framework that's been happening lately, Stan Lemon thought it would be interesting to see how a microframework based on the Aura packages would be to create. He's posted about his experiences on his site today.

I was recently working on a small project that used Silex. As I browsed my vendor folder, I realized how much extra "stuff" I had inherited with Silex. There were a bunch of other components required when all I wanted was some quick and easy routing, micro-framework style. When I think about going lean I always find myself coming back to Aura. Micro-frameworks are not a new to idea to Aura, so I wondered if I could take the elegance and ease of Silex by wrapping up Aura.Router and exposing it through a similar API.

The result of his work is Aura.Micro, a simple microframework that really just handles routing (unlike Silex with builds on the Pimple DI as well). He includes an example of it in use, defining several different kinds of actions on the routing like "before", "finish" and a few "get" routes.

In this new post to his site Volker Dusch talks about some of his first experiences with the Silex microframework (from the folks behind Symfony) and the evolution his code went through in its first few versions.

A couple of weeks ago Igor wrote a fantastic blog post about "Scaling a Silex code base" which made me remember a story I wanted to share about how I fell in love with Silex. This blog post aims to tell that story. If you never heard of Silex is let me paste the blurp from the silex home page for you: "Silex is a PHP microframework for PHP 5.3. It is built on the shoulders of Symfony2 and Pimple and also inspired by Sinatra."

He talks about some of his "first steps" with the framework and their need for a smaller system that could run embedded on a local machine. He talks about how Silex let him rapidly prototype and develop the application with only what was needed. He shows the evolution of his route handling from simple closures to method calls on objects out to using providers.

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.

Igor Wiedler has a new post to his site today talking about scaling Silex-based applications (a microframework based on Symfony components) and using it for more than just the basic applications.

One common misconception about silex and microframeworks in general is that they are only suited for small, simple apps, APIs and prototyping. Of course, those use cases are the main selling point, but they are by no means the limit of what is possible.

He shares some code that's the common "first steps" for someone using the framework, but points out a better way - moving your controller handling out into separate files instead. With a built-in feature of Silex, you can specify the "path" to another class file that will handle the request and return the response back to the main app. He also suggests extracting even more of the functionality out into "service" classes to handle the processing, cleaning up the controllers even more. He finishes off the post with a brief comparison between Silex and a full Symfony2 application, noting that Silex is a bit more "free form" when it comes to structure where Symfony2 apps are pretty well defined and have their conventions.

Dave Marshall has written up a post about how he uses Silex controllers as services that allow him to define his controller methods in separate classes with a custom resolver.

There's currently a pull request in the queue for Silex that adds a cookbook entry for using controller classes, but I wanted to take it a step further and have my controllers as services, much like what's possible with the full symfony framework (See Richard Miller's post for further reading).

He includes some example code showing the creation of the Silex application with a service definition, the custom "ControllerResolver" to override the default and a simple controller class ("PostController") that just returns a JSON response. You can find the full example code for it on github.

Matthew Weier O'Phinney has been doing some research into PHP microframeworks lately and has shared some of his thoughts in the latest post to his site.

PHP has had microframeworks for quite some time, though I only really first saw the term being used around 3 years ago. The "grand-daddy" of modern-day microframeworks can actually be traced to Ruby, however, and specifically Sinatra. [...] Since around 2009, I've seen an increasing number of new PHP microframeworks4 that follow in the steps of Sinatra and Horde. In the various implementations I've looked at, instead of using a DSL, the authors have all opted for either a procedural or OOP interface.

He gives some code examples showing how the typical routing has been handled in most of the frameworks he's seen and how they handle passing values back to the handler. He sees three use cases for frameworks like this including small, mostly static sites and APIs. He also mentions his efforts to create a microframework using components from the Zend Framework 2 (not released). He finishes up the post with some of his own conclusions about microframeworks and the lessons he learned from his efforts.