Pragmatism in the real world
Eloquent is one of the easier ORMs to get started with, so let's look at how to use and test it within a Slim Framework application. Set up You can add Eloquent to your Slim project via composer: composer require illuminate/database You now need to bootstrap it. To do this we need some settings, so lets do that in our standard Slim configuration: $config = [ 'settings' => [ 'db' => [ // Eloquent configuration… continue reading.
Configuration in Slim Framework is nice and simple: the App's constructor takes a configuration array for the DI container; $config = []; $app = new Slim\App($config); Setting up The settings sub-array is used to hold the settings of your application: $config = [ 'settings' => [ 'displayErrorDetails' => true, 'logger' => [ 'name' => 'slim-app', 'level' => Monolog\Logger::DEBUG, 'path' => __DIR__ . '/../logs/app.log', ], ] ]; $app = new Slim\App($config); Slim comes with a number… continue reading.
To test a Slim Framework action, you need a request and a response object and mock whatever is in the action. This is one way to do this. Consider this simple echo action that returns the query parameters to you as a JSON encoded string: $ curl "http://localhost:8888/echo?foo=bar&this=that" {"foo":"bar","this":"that"} This is one of those useful API endpoints that your users can use to check that everything is working as expected. The action under test The… continue reading.
We released Slim 3.2.0 yesterday which includes a number of minor bug fixes since 3.1.0 and also a few nice improvements around the way we handle errors. Writing to the error log Slim has a simple exception handler implemented that displays an error page that looks like this: It's not very informative, is it? That's intentional as we don't want to leak information on a live website. To display the error information you need to… continue reading.
Handling file uploads in Slim 3 is reasonably easy as it uses the PSR-7 Request object, so let's take a look. The easiest way to get a Slim framework project up and running is to use the Slim-Skeleton to create a project: composer create-project slim/slim-skeleton slim3-file-uploads and then you can cd into the directory and run the PHP built-in web server using: php -S 0.0.0.0:8888 -t public public/index.php Displaying the form We can now create… continue reading.
Having installed Phan, I decided to use it against the upcoming Slim 3 codebase. Phan needs a list of files to scan, and the place I started was with Lorna's article on Generating a file list for Phan. I started by removing all the developer dependencies: $ composer update –no-dev and then built the file list for the vendor and Slim directories. I started by using Lorna's grep statement, but that found too many non-PHP… continue reading.
I released Slim 3 RC 2 today after a longer than expected gap from RC1. The gap was caused by two things: Real LifeTM was busy for all the core team members People test RCs, but not betas! Obviously, the important one here was testing. Thank your everyone who tested RC1! As a result, a number of important issues were raised after RC1 was released which we had to address. Two key BC-breaking ones involved… continue reading.
From RC1 of Slim 3, we have improved our error handling. We've always had error handling for HTML so that when an exception occurs, you get a nice error page that looks like this: However, if you're writing an API that sends and expects JSON, then it still sends back HTML: At least we set the right Content-Type and status code! However, this isn't really good enough. We should send back JSON if the client… continue reading.
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.
