Month: November 2010

A First Look at Fuel

UPDATE: I didn’t really mention that Fuel is an open source project. If you want to help out, head over to their github page, fork your own repo and get submitting!

UPDATE UPDATE: I’m not actually affiliated with the Fuel project, just a user. Please direct all suggestions over to their contact form or comment on github. thanks 🙂

There was an announcement a while back from Phil Sturgeon and a few others (shortly after some issues came to light with a certain other framework) about a new framework they were developing that came to be called Fuel. According to their site, the goal is to be:

a simple, flexible, community driven PHP5 framework. FUEL aims to take the best idea’s from a bunch of frameworks, throw away the “not so good” stuff, and create one awesome framework. It is provided under the terms of an MIT License, which means it’s free to use in your personal, commercial or enterprise projects.

What’s that? Why does the web need another framework? Well, to be honest, it doesn’t – but there is one thing that Fuel has going for it. If you’re one of the many CodeIgniter users out there, you’ll feel almost immediately comfortable with it. Since the devs are CodeIgniter fans themselves, they’ve built a lot of the same feel into how Fuel handles your applications. Unfortunately, there’s not a user guide for it yet, so I figured I’d share some of my experiences with it and maybe get you set down the road to fuel-ing your app (yep, that cheesy pun was required).

So, to get started, here’s some simple installation instructions:

  • Grab the latest source from Github (this will probably change when they make releases)
  • Unpack the files into a web-accessible directory. Mine are in /www/htdocs/fuelapp
  • There’s a /public directory in there – that’s where you need to point the DocumentRoot to
  • Make sure that AllowOverrides is set to use .htaccess and that mod_rewrite is installed and working
  • Move the “example.htaccess” file over to just “.htaccess” to make the rewrites work
  • At this point, when you visit the host for your site, you should get the “Welcome” message
  • Be sure to chmod the app/cache and app/logs directories so that the web server user can read/write to the directories.

That should get you started and have your basic application structure all set to go. In the basic layout, your application will live in the /app directory (makes sense, eh?) with the actual framework living in /core. As far as the three pillars of a MVC framework – they’re in classes/controller, classes/model and views. There’s also a config directory that houses the configuration files for your application.

Let’s start with the controllers – here’s an example snippet from the welcome controller showing you a basic controller structure:

[php]
<?php

use FuelController;

class Controller_Welcome extends ControllerBase {
public function action_hello()
{
$this->output = ‘Hello ‘.$this->param(‘name’);
}
}
[/php]

This action is called at http://localhost/welcome/hello (obviously replacing the hostname with yours).

If you haven’t seen something like the “use” call before, don’t worry. It’s just namespacing. The framework is PHP 5.3 only, so they can use fun things like namespacing and closures. In the example above, they load the FuelController namespace and extend the ControllerBase by default. There’s some naming conventions to look out for in controllers:

  • Controller class names should be “Controller_*”
  • They should extend ControllerBase
  • Methods should be “action_*”
  • Output pushed to the view belongs in $this->output

Something you don’t see in the above example is how to interact with the view. You’ll need to use the View class to get your data loaded into the right place. Here’s an example of that:

[php]
public function action_index()
{

$arr = array(
‘data’ => ‘test data’,
‘partial’ => View::factory(‘test/partial’)->render()
);

$this->output = View::factory(‘test/index’,$arr);

}
[/php]

If you’re quick, you’ve spotted the “partial view” I’ve simulated. By calling that “render” method on the view object, it returns the results as a string that can be appended. The parameter in that “factory” call is the path to the view file. So, the string “test/index” refers to the file /app/views/test/index.php.

There’s already some handy built-in helpers for the framework. It seems like all of them I saw were able to be called statically. So, for example – here’s how you could use the Uri helper:

[php]
public function action_uri()
{
$detect = Uri::detect();
var_dump($detect);
}
[/php]

Oh, and one last thing I know some of you are wondering about – database connectivity. Right now, there’s only MySQL connectivity, but I’m sure that’ll change quickly. Here’s a simple database example to get you started:

[php]
public function action_database()
{

$db = Database::instance();
$tables = $db->list_tables();
var_dump($tables); echo ‘<br/><br/>’;

$result = $db->query(Database::SELECT,’select * from test_data’,false);
var_dump($result); echo ‘<br/><br/>’;

var_dump($result->current());
$result->next();
var_dump($result->current());

$this->output = ‘test’;
}
[/php]

Instead of just returning arrays or whatever, the datbase calls by default return iterators. I nice touch in my opinion that could go a long way to help SPL adoption. You can also define an object type on the “query” call that lets you map to and object type.

So far so good…like I said, if you’re a CodeIgniter fan, you’d do well to check out Fuel. It feels more like what CodeIgniter should be when it grows up and joins the rest of the PHP frameworks in the PHP5+ world. I’ve already submitted a small update back to the framework and can already say that the community for it is friendly and open to whatever help they can get. Dan Horrigan, Phil Sturgeon and Jelmer Schreuder are doing a great job so far and I look forward to some more great things to come.

I’m going to continue messing with it and will try to post any fun things I might come across. Feel free to ask me about installation or some of the basics of the framework. I’m happy to share what I know.

Oh, and for those wondering, here’s my sample controller I’ve pulled these samples from:

[php]
<?php

use FuelController;

class Controller_Test extends ControllerBase
{

public function action_index()
{

$arr = array(
‘data’ => ‘test data’,
‘partial’ => View::factory(‘test/partial’)->render()
);

$this->output = View::factory(‘test/index’,$arr);

}

public function action_caching()
{
Cache::set(‘mykey’,’testing’);
$cacheOutput = Cache::get(‘mykey’);

$this->output = ‘cache output: ‘.$cacheOutput;
Cache::delete(‘mykey’);

$this->output.=’cache after: ‘.Cache::get(‘mykey’);
}

public function action_uri()
{
$detect = Uri::detect();
var_dump($detect);
}

public function action_database()
{

$db = Database::instance();
$tables = $db->list_tables();
var_dump($tables); echo ‘<br/><br/>’;

$result = $db->query(Database::SELECT,’select * from test_data’,false);
var_dump($result); echo ‘<br/><br/>’;

var_dump($result->current());
$result->next();
var_dump($result->current());

$this->output = ‘test’;
}

}

?>
[/php]

One ToDo list to rule them all?

Okay, so _ I’m going to put this out there so I can get some feedback. I’m looking for a good To Do list manager with a few criteria:

  • I’d love for it to have desktop software that would sync with the site (or some other resource) and allow me offline access to the lists
  • It needs to be able to prioritize items
  • It should definitely allow main and sub-categories (one level of categories? that’s crazy talk)
  • The desktop software would need to be cross-platform (pc & mac) – maybe an AIR client?
  • Bonus points if it allows sharing between users or just public access to the lists (RSS?)
  • Mobile support is cool, but not required

I like the simplicity of some of the tools out there, but none of them seem to meet what I’m looking for. Is there anyone out there that’s come across something like this? It’s driving me nuts that there’s not one that’ll fit my needs.

A Partial Review of “Test-Driven JavaScript Development”

So ever since the fine folks at Addison Wesley sent over a copy of Test-Driven JavaScript Development (by Christian Johansen) I’ve been trying to wrap my head around a new sort of testing when it comes to web apps. I’m not even half-way through the book and I’ve already had my mind blown by advanced javascript and testing methods that I just never thought about when I work on my frontends.

I’m a big fan of unit testing and promote it whenever I can – not only does it help create a code base that a better quality, but it also lets you keep things consistent. No more of the “cross your fingers” kind of coding. A good, well-written set of unit tests can save you a whole world of hassle in the long run. Taking it one step further, you get to TDD (test-driven development) where you write your tests before you even write your code. You start with the usual “W”s – why, where, when, how (yes, I know that last one’s an “H”s) and develop the test for those rather than looking at a current chunk of code and testing what it already does. There’s some people that swear by it, one of them being the author of this book.

He starts with an introduction to TDD and a general how-it-works with javascript quickly followed by an introduction to his tool of choice – JsTestDriver. All of the test examples in the following chapters are run with this tool. Thankfully it’s simple to set up and even easier to write tests for. He shows some introductory tests to help you get familiar with things before diving into the next section – testing javascript itself.

I have to admit, this section left me at a loss for words. I thought I knew a good bit about how javascript works, both out in front and behind the scenes. I was surprised, however, just how much of the functionality he tested I had no idea worked that way. It’s pretty in-depth, so if you’re a beginning javascript dev, you might go read some more tutorials before diving right in.

I’m just now getting to the “Unobtrusive Javascript” part of the book (Part 2, Chapter 9) so I still have a ways to go, but each page is enlightening, especially for some one like myself that’s has a primary focus on backend work and unit testing. I’d definitely recommend this book to anyone looking to get into testing their frontends – it’s a great resource and can probably teach you a thing or two.

I’ll try to put up another post when I get closer to the end – it’s hard to find time to sit and read these days, but just little nibbles at a time work just fine.