So things have gotten a bit out of control, and I haven’t had time to keep working on Slim. I’ll get back to it in a few weeks.

Posted in Uncategorized | Leave a comment

Slim: Our first view

Unlike more full featured frameworks, there isn’t much about Slim that is configured out of the box—at least based on what I’ve seen so far. Take views for example. Unlike a traditional MVC framework there isn’t a folder already designated for views. Since we’ll more than likely want to use views before this is all over, let’s work on configuring Slim and setting up our first view.

The Slim documentation refers to view files as templates. Indeed the config parameter we’ll be setting is called template.path. With that in mind, I added a templates folder to my [project] folder. I also created a css and img folder in my public folder. My folder structure now looks like this:


In order to let Slim know where the templates can be found, we need to pass some parameters to the constructor. The Slim constructor takes an associative array of parameter values.You could keep it simple and create your Slim app like this:
$app = new Slim( array(
     'template.path' = '../templates'

That’s not going to be a very practical solution in the long run. If you look at what Jeremy Kendall did in his Flaming Archer project, he creates a config.php file in the [project] folder and puts all of his config values there, then uses a require statement to get them into his app.

I have some reservations with Jeremy’s approach. With the config file in the project folder, it does make it easy to use __DIR__ to build your paths with. However, I’m not a fan of using a return value at the end of an include file. If adding a return statement at the end of an external PHP file did some kind of magic so that the file was scoped like a function, I would probably be OK with that approach. I’m not opposed to magic on principle. Unfortunately, that is not how it works. Variables declared in the config file are still floating around in the global scope. In the interest of keeping things a bit more tidy, I’m going to take a different approach.

No doubt at some point in this process I’m going to need to write my own classes that I will need to make available to Slim. Since we are using Composer to load our classes, we need to tell Composer where to find the files. I’m going to make an ‘classes’ folder in my project folder. To quote Tolkein, “A precise if not too imaginative name…” There doesn’t seem to be much of a convention as to what this folder should be called. Feel free to name your folder whatever you like.

Now we’re going to open up our composer.json file and some more info:

   "require": {
        "slim/slim": "2.3.*",
    "autoload": {
            "Dezynworks": "classes/"

Basically what we’re telling composer is “you can find the namespace Dezynworks in the classes folder.” Don’t forget that comma after your require object or you won’t have valid JSON. Next we need to make a Dezynworks folder in the include folder. Obviously, you can call your namespace whatever you want. If for some odd reason you go ahead and call it Dezynworks, I promise I won’t sic my lawyers on you. Now we have a folder structure that looks like this:


Since we’ve modified the composer.json file, we need to update Composer so it knows about the change. From the command line run php composer.phar update. Now that we have told Composer where to find our namespace, let’s get going. I’m going to create a Config class and stick it in my classes/Dezynworks folder.


namespace Dezynworks;

class Config{
  public static function slim(){
    return array(
        'templates.path' => $_SERVER['DOCUMENT_ROOT'] . '/../templates',

I’m sure that seems a bit over engineered for a single parameter, but it’s unlikely that’s the only parameter we’re going to need before we’re done. It’s also likely we’ll add a few more libraries that will need their own config parameters. Setting up a config class this way keeps the global scope tidy, puts all our config parameters in one place and allows us to keep them as organized as suits our our personal levels of OCD.

Now we edit our index.php file so the call that creates our Slim object to look like this:

  require '../vendor/autoload.php';

  use Slim\Slim;
  use Dezynworks\Config;

  $app = new Slim( Config::slim() );

Now that Slim is ready, let’s create our first template. In the templates folder, I’ll create a layout.php file that looks like this:

<html lang="en-US">
        <meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
            <title>Dezynworks | Web Development and Design</title>
        <?= $content ?>

Now we need to modify our router call.
  $app->get('/', function() use ($app) {
    $app->render( "layout.php", array(
      'content' => "Hello again."

A few things of note here. First, we can’t call the render function of the app from within our anonymous function because the $app variable doesn’t exist within that scope. The use statement takes care of injecting $app into the function scope. Now we can call $app->render() and give it the name of our template file which Slim can find thanks to all the leg work we just did. It should be fairly obvious how we got our $content variable passed into our template. Till next time.

Posted in PHP | Tagged , | Leave a comment

boagworld.com Podcast

I’ve started listening to the podcast produced by the gents at boagworld.com. I like their format of making a proposition and then discussing pros and cons, including comments left from the web site. Apparently it’s been around for a while, so I’m just coming late to the game. If you’re like me and haven’t checked it out, pop over and give a listen.

Posted in News | Tagged | Leave a comment
    • Aviation University.com
    • HopsAndGears.com
    • tds1
    • ogio1
    • Aegis