Pragmatism in the real world
In addition to the core Slim framework, we also ship a number of add-ons that are useful for specific types of problems. One of these is Slim-Csrf which provides CSRF protection. This is middleware that sets a token in the session for every request that you can then set as an hidden input field on a form. When the form is submitted, the middleware checks that the value in the form field matches the value… continue reading.
In my Slim 3 skeleton, I chose to put each action into its own class so that its dependencies are injected into the constructor. We then register each action with the DI Container like this: $container['App\Action\HomeAction'] = function ($c) { return new App\Action\HomeAction($c['view'], $c['logger']); }; In this case, HomeAction requires a view and a logger in order to operate. This is quite clear and easy. However, it requires you manually register each action class with… continue reading.
One feature of Slim 3 is that the DI container is loosely coupled to the core framework. This is done in two ways: The App composes the container instance rather than extending from it. Internally, App depends on the container implementing the container-interop interface. You can see this decoupling in the way that you instantiate a Slim 3 application: $settings = []; $container = new Slim\Container($settings); $app = new Slim\App($container); Slim 3 ships with Pimple… continue reading.
Last night, I tagged beta 1 of Slim Framework 3! This is a significant upgrade to v2 with a number of changes that you can read on the Slim blog. For me, the two key features that I'm most excited about are: PSR-7 support, along with the standard middleware signature of: function($request, $response, $next) { return $response; } Dependency injection container with container-interop compliance. We ship with Pimple by default, but I'm planning to use… continue reading.
One of the changes between Slim Framework 2 and 3 is that the application singleton has gone. In Slim 2, you could do this: $app = \Slim\Slim::getInstance(); // do something with $app In general, you didn't need access to $app itself, but rather you wanted access to something that the app knows about, such as a database adapter, or the router for access to the urlFor method to create a URL to a route. With… continue reading.
Warning Slim 3 is currently under active development. Expect BC breaks! I'm creating a number of projects in Slim 3 (which is currently under development) at the moment in order test things out and found that I was setting them up in essentially the same way. To save me having to do this each time, I've now created a skeleton project that is set up with the directory structure that I like and also includes… continue reading.
Sometimes you need more configuration flexibility for your application than a single array. In these situations, I use the Zend\Config component which I install via composer: composer require "zendframework/zend-config" This will install the Zend\Config component, along with its dependency Zend\Stdlib. Let's look at a couple of common situations. Multiple files It can be useful to to split your settings files out for administrative or environment-specific reasons. To set up within a Slim application, you do… continue reading.
Slim Framework 3 is being actively developed at the moment and has a number of changes in it, including the use of the Pimple DI container and an overhaul of pretty much everything else! In this post, I'm going to look at error handling. The default error handler in Slim 3 is Slim\Handlers\Error. It's fairly simple and renders the error quite nicely, setting the HTTP status to 500. I want to log these errors via… continue reading.
