This time is the latter. I was, as it is not uncommon in me, tweeting about how questionable Apple policies are when it comes to the work environment in their factories, when Felix, a person who I have the strongest respect for, tweeted something that got my attention:

by that logic, you are responsible or every action taken by every company you purchase from

My quick response to him is a thought I wish to ellaborate:

and you are. thats the point im making. we should do our best to avoid supporting companies that WE KNOW are being evil

If one would boycott all companies that are, at one level or another, doing evil, one would probably have to live alone, in the middle of the desert, consuming nothing but vegetables. I know that’s not practical. However, we have to draw the line somewhere, right? And don’t you think that a company that supports, by action or inaction, job environments that are universally accepted as inhuman is somewhere near the line? To give you a bit of background, look at this interview Bill Maher did shortly ago with Mike Daisey (it’s less than 8 minutes long, you have the time):

I’m sure I am backing other companies that may be acting immorally somewhere around the globe, but if I know they are, I will do my best to avoid giving them business, and so should you. If I knowingly give them business I am partly responsible for their wrong doings. I know that’s not something you’d like to hear, but that’s a fact.

There will be times where it feels almost impossible to take your business elsewhere. Apple lovers will tell me (and they would mostly be right) that there is no better phone than the iPhone. That the iPad is miles ahead of any other tablet. I know, I get it. They build nice products. But at what cost? Would you rather buy the nice cars that come out of a factory in Nazy germany, or would you like to help Germany (and the rest of the world) free itself from the Nazi horror? I prefer to do the later. Now, please, don’t panic, I am NOT saying Apple is pro-Nazi (that’s a comparison that has been largely misused), that’s just an extreme example to make a point. I am saying that we all know that they are doing something that’s quite wrong, so we should do our best to stop supporting them.

So even when I always thought I should be a responsible buyer, I am now making an extra effort: I will try to inform myself, to the best of my abilities, about what lies behind the product I’m buying. If it is a sweat shop in Asia, I’m out. If it’s cheap because it’s based on child labor, I’m out. I am morally responsible for my purchases, so I will act accordingly. I may sometimes, inadvertently, support evil companies. If so, I wish to have the capacity to find out about it, and stop supporting those companies.

Let us do this together, shall we?

No related posts.

People often think that when you are coding PHP you have to do things “the PHP way”. Well, let me clear it up for you: there’s no such thing as “the PHP way”. If there’s something that defines PHP is its flexibility to be as ugly or as beautiful as you want it to be. With that in mind, what prevents you from taking the lessons learned in one language to another?

That’s the premise I always have when I’m coding. Let me give you a for instance. On Node.js, I normally use express.js as a framework. Check it out, it’s pretty awesome. One of the things I love in express.js, is its route middleware capabilities. When I code in any PHP framework, that’s one of the things I miss the most.

Not many PHP frameworks are flexible enough to support such concepts. One of them is, though. Lithium has many of the things I love about PHP (5.3+ obviously, as I consider anything < 5.3 a waste of my time lately), and some of the things I love about other languages. One of them is Lithium’s addiction to closures. I love it. They allowed me to take the concept of express.js’ route middleware and apply it to my PHP code.

Let’s start with a dummy application skeleton. A users table:

CREATE TABLE `users`(
    `id` INT NOT NULL AUTO_INCREMENT,
    `email` VARCHAR(255) NOT NULL,
    `password` VARCHAR(255) NOT NULL,
    PRIMARY KEY(`id`)
);

INSERT INTO `users`(`email`, `password`) VALUES(
    'test@email.com', '$2a$04$U7qYPVYq2YBxqfHL8F2pteERxQYwLTVtAjMIh48Lef9sLSiMVtGHy',
    'john@email.com', '$2a$04$U7qYPVYq2YBxqfHL8F2pteERxQYwLTVtAjMIh48Lef9sLSiMVtGHy'
);

In your app/config/bootstrap/connections.php, make sure you uncomment the default database and hook it up to the database owning the table we just created. We’ll also be using sessions, so uncomment the session.php reference in app/config/bootstrap.php. You may have noticed that our initial users have a password set to a specific value, which means a specific salt was used (the password hashed there in plain text is ‘password’, minus the quotes.). So go ahead and add the following to your app/config/bootstrap/session.php file:

use lithium\security\Auth;
use lithium\security\Password;

$salt = '$2a$04$U7qYPVYq2YBxqfHL8F2pte';
Auth::config(array(¬
    'adapter' => 'Form',
    'model' => 'Users',
    'filters' => array('password' => function($text) use($salt){
        return Password::hash($text, $salt);
    }),
    'validators' => array(
        'password' => function($form, $data) {
            return (strcmp($form, $data) === 0);
        }
    ),
    'fields' => array('email', 'password')
));

The salt was generated with a call to \lithium\security\Password::salt('bf', 4). I always use blowfish for password hashing (and 2^16 iterations in production). If you don’t use blowfish, here’s why you should. Anyway so you may want to store the hash on a better, configurable approach. I opted for a simple variable for this example. Once the salt is defined, I went ahead and configured Auth to use lithium’s Password::hash() method for hashing using the generated salt, and telling it how to compare hashed passwords against the database value. Pretty simple.

Let’s now build the Users model. It won’t have anything in there, really. So just create your app/models/User.php file with the following contents:

<?php
namespace app\models;

class Users extends \lithium\data\Model {
}
?>

Now the controller. Create a file named app/controllers/UsersController.php with the following contents:

<?php
namespace app\controllers;

use lithium\security\Auth;

class UsersController extends \lithium\action\Controller {
    public function login() {
        if (!empty($this->request->data)) {
            $user = Auth::check('default', $this->request);
            if ($user) {
                $this->redirect(array('action' => 'view', 'id' => $user['id']), array('exit' => true));
            }
        }
    }

    public function logout() {
        Auth::clear('default');
    }
}
?>

Nothing really complicated there. Don’t forget the view in app/views/users/login.html.php:

<?php
echo $this->form->create();
echo $this->form->field('email');
echo $this->form->field('password', array('type' => 'password'));
echo $this->form->submit('Login');
echo $this->form->end();
?>

That should give you a working login / logout. Add some dummy actions to the UsersController.php file:

public function view() {
    echo 'view';
    $this->_stop();
}

public function edit() {
    echo 'edit';
    $this->_stop();
}

Ok now we are ready to play with some route middleware. What we want to achieve is the following:

• No action named edit, on any controller, should be accessible without a logged in user.
• When accessing either the Users::edit or Users::view action, there should be an ID specified as a route parameter, and it should match an existing User record.
• When accessing the Users::edit action, the given user should match the currently logged in user.

These are pretty basic security checks that you would normally put on the controller. Not this time. Edit your app/config/routes.php file and add the following right below the use statements found at the beginning of the file:

use lithium\net\http\RoutingException;
use lithium\action\Response;
use lithium\security\Auth;
use app\models\Users;

These are all classes that we will use in our route middleware. Let’s start with the first checkpoint we want to achieve: “No action named edit, on any controller, should be accessible without a logged in user“. Add the following to the routes.php file, below the content we just added:

Router::connect('/{:controller}/{:action:edit}/?.*', array(), array(
    'continue' => true,
    'handler' => function($request) {
        if (!Auth::check('default')) {
            return new Response(array('location' => 'Users::login'));
        }
    }
));

The first parameter (continue) ensures that this route definition is treated as a continuation route. This is because we don’t want to interrupt any normal route / parameter processing in this definition. We just wanna “grab” all calls to any edit action, and check (using Auth) for a valid user. If none is found, we process the request by returning a Response, which in the end redirects the user to the login page. If there is indeed a logged in user, the router will continue looking for other route definitions to match the request. So now all edit actions require a logged in user. Cool.

Next in our list: “When accessing either the Users::edit or Users::view action, there should be an ID specified as a route parameter, and it should match an existing User record.” Add the following to the routes.php file, below the content we just added:

Router::connect('/{:controller:users}/{:action:edit|view}/{:id:\d*}', array('id' => null), function($request) {
    if (empty($request->params['id'])) {
        throw new RoutingException('Missing ID');
    } elseif (!Users::first(array('conditions' => array('id' => $request->params['id'])))) {
        throw new RoutingException('Invalid ID');
    }
});

We are now getting more serious. In this definition, we are only matching the Users controller, and actions named either edit or view, which may or may not contain an id parameter. The route handler first checks to make sure the id parameter is given (if not, a RoutingException is thrown.) If the parameter is specified, it is used to find a matching User record with the given ID. If none is found, yet another RoutingException is thrown (you may wish to do something different here, like ensuring a 404 status). If the user is found, the route is not handled, which means some other route definition will handle it (the default route, in this case.)

The final checkpoint we have is: “When accessing the Users::edit action, the given user should match the currently logged in user.” So add the following to the routes.php file, below the content we just added:

Router::connect('/{:controller:users}/{:action:edit}/{:id:\d+}', array('id' => null), function($request) {
    $user = Auth::check('default');
    if ($user['id'] != $request->params['id']) {
        throw new RoutingException('You can only edit your own account');
    }
    return $request;
});

This defines a specific match to the Users::edit action with a set id parameter. We use that parameter to make sure it matches the ID of the logged in user. If it doesn’t match, we throw a RoutingException. If it does match, we return the request as we have successfully processed it.

You can now try accessing the edit and view actions using different scenarios: with a logged in user, while being logged out, editing a user which is not the current logged in user, etc. Everything should be nicely protected. And yet our controller code remained untouched. Nice, huh? That’s routing middleware for you.

No related posts.

While working on it, I tried to aim for developers at different levels of knowledge, yet a disclaimer has to be made: this is not a beginners book. It will not teach you how to install CakePHP, or how to get its friendly URLs working on Microsoft platforms (dodged that bullet.) It is written for CakePHP developers that are looking to solve different problems, and leverage their own applications. So no “building a blog” chapter in this book.

There are some recipes that deal with more complex topics, while others deal with what I consider interesting solutions to simple problems. Each recipe starts by proposing a problem, showing the solution, and giving an explanation of how the solution works. Most of the recipes include alternatives and extend the topic at hand beyond the scope of the problem they are solving, and some of them are based on open source packages that CakePHP community members (myself included) released.

This book also benefited from an unbelievably, super-cool, top of the world team of technical reviewers (the CakePHP 1.3 lead developer happens to be amongst them) that made its code shine (I am known for being humble.) They improved each recipe and proposed awesome alternatives to my original ideas. Because of that, this blog post is being written. I’m not sure sure I would’ve been as proud of the original version of the book

You should also know that the publishing company behind the publication of this book, Packt Publishing, is donating an important portion of the book earnings to the Cake Software Foundation, which is like The Force behind CakePHP. So I might not get rich, but at least the foundation will get some beers out of each sale. And trust me, nothing says thank you like a beer.

If you bought the book, I welcome any feedback you may have (you could also leave a review and tell others how super cool the book is.) If you are more of a bytes person and less of a paper person, and look forward to reading the digital version, you can also get the ebook.

No related posts.

You can of course find an easy solution: build a multipart request by building the request body yourself out of the files you are trying to upload. Sure, that works. But what happens when you are dealing with a 50 MB file upload? What about 500 MB? I’m sure you are not planning to encode the whole file as a string, right?

This is where Twisted’s body producers come handy. Implementing your own body producer, you have total control on how to build the request. In fact, Twisted will call you every time it needs data for the request, so you can be sure you won’t be building the whole chunk in one string. Instead, you will be sending chunks of bytes to what is known as the consumer. What is the consumer? Whatever is asking for a request body.

Ok, enough said. I could go on and on with the explanation, but let’s learn by coding (yay!.) We want to upload a file to a server using Twisted. We also want to know how the file upload is doing (by getting progress callbacks), and when it finishes. Just for the fun of it, we will also send other POST data with the request.

First things first, let us build the server code that will handle the upload. For simplicity (well, that’s sort of B.S., since Python is simple enough) we’ll build a PHP script that will take a file upload, and print out the uploaded information, together with any posted data. Here’s the code for that:

<?php
$files = array();
foreach ($_FILES as $field => $file) {
	if (empty($file['tmp_name']) || !is_uploaded_file($file['tmp_name'])) {
		continue;
	}
	$files[$field] = $file;
}

print_r($_POST);
print_r($files);
?>

Easy right? We are just printing out whatever we got, discarding any invalid file upload information.

Let’s look at our client to upload a file, and POST some data to this PHP script. This Python script is using the body producer I built, together with a handy receiver for getting the response. More about that later. Here is the client script:

from twisted.internet import defer
from twisted.internet import reactor
from twisted.web import client
from twisted.web import http_headers

from pyfire.twistedx import producer
from pyfire.twistedx import receiver

def finished(bytes):
	print "Upload DONE: %d" % bytes

def progress(current, total):
	print "Upload PROGRESS: %d out of %d" % (current, total)

def error(error):
	print "Upload ERROR: %s" % error

def responseDone(data):
	print "Response:"
	print "-" * 80
	print data
	reactor.stop()

def responseError(data):
	print "ERROR with the response. So far I've got:"
	print "-" * 80
	print data
	reactor.stop()

url = "http://kramer/upload.php"
files = {
	"upload": "/home/mariano/myfile.tar.gz"
}
data = {
	"field1": "value1"
}

producerDeferred = defer.Deferred()
producerDeferred.addCallback(finished)
producerDeferred.addErrback(error)

receiverDeferred = defer.Deferred()
receiverDeferred.addCallback(responseDone)
receiverDeferred.addErrback(responseError)

myProducer = producer.MultiPartProducer(files, data, progress, producerDeferred)
myReceiver = receiver.StringReceiver(receiverDeferred)

headers = http_headers.Headers()
headers.addRawHeader("Content-Type", "multipart/form-data; boundary=%s" % myProducer.boundary)

agent = client.Agent(reactor)
request = agent.request("POST", url, headers, myProducer)
request.addCallback(lambda response: response.deliverBody(myReceiver))

reactor.run()

Let’s look at what we are doing here. We start by importing some twisted modules we need for this script, and the multipart and receiver modules from the pyfire module I wrote. Don’t worry, you don’t have to use pyfire to use these two modules. Just make sure to download the twistedx module that is part of pyfire. Next, we define some callback functions: finished() to inform that the upload is done, progress() to keep us in the loop while the request is being sent to the server, error() in case sh*t happens, and finally responseDone() and responseError() to handle the response from the server, and stop Twisted’s reactor (its event loop.)

In the actual script code we see that we start by defining the destination URL, and dictionaries with the files to be sent out, and data to post, both of them indexed by field name. We proceed then to start coding the “Twisted” way: creating two deferreds that will be used by the producer, and the receiver. If you don’t know about deferreds you probably haven’t read the Twisted manual much, so I recommend you go over their section on deferreds. Basically it’s a very easy (and flexible, and chainable, and…) way to get callbacks.

So we build two deferreds: the first one (producerDeferred) is for the producer, where we attach a success callback (the finished() function), and an error callback (the error() function). The second one (receiverDeferred) is used by the receiver, and contains a success callback (the responseDone() function), and an error callback (the responseError() function). Both of these functions will print out whatever data we got as response, and finish by stopping the reactor.

We then build the producer, passing on the files to upload, the data to post, the callback progress() function that will be called throughout the upload, and the deferred for the producer. Similarly, we build the receiver, passing only its deferred.

Having both the producer and the receiver, we can now proceed to create the actual request, not without first creating any additional headers we may need (the request will automatically specify the content length out of the body producer.) Since we are uploading a file, we specify the content type of the request to be multipart/form-data, and as its boundary we set whatever the producer chose as boundary for our chunks in the request body.

The final step is the actual running of the request, doing it the typical Twisted way: first getting an agent for the reactor, creating the request (a POST request to the given URL, with the given headers and body producer), and adding a callback for when we get a response. The callback in this case is a simple lambda function, that delivers the body from the response to the receiver. Finally, we run the reactor.

Notice that when you run the reactor the run() call will block until you stop the reactor. This is why from our response callbacks (responseDone() and responseError()) we stop the reactor whenever we get some sort of response.

If you run this script against your PHP server script, you may get an output like the following:

Upload PROGRESS: 153 out of 9120
Upload PROGRESS: 320 out of 9120
Upload PROGRESS: 9080 out of 9120
Upload PROGRESS: 9082 out of 9120
Upload PROGRESS: 9120 out of 9120
Upload DONE: 9120
Response:
--------------------------------------------------------------------------------
Array
(
    [field1] => value1
)
Array
(
    [upload] => Array
        (
            [name] => myfile.tar.gz
            [type] => application/x-tar
            [tmp_name] => /tmp/phplINynd
            [error] => 0
            [size] => 8760
        )
)

Isn’t this fun?

No related posts.

Before we proceed, a disclaimer. This tutorial shows a rather quick and dirty integration with Doctrine (as you’ll see it’s all mostly done in a base model class), while the most clean approach would be to implement all this as an extension, using Datasources and Query parsing. I’m happy to say this is all being done as we speak (thanks kuja!), so very soon you’ll find an even better approach to Doctrine integration.

Other Lithium Tutorials

Of course I’m not the only one to have written about Lithium! Here are some tutorials you may enjoy:

• Video Tutorial: li3 on Apache2, and li3 on IIS7.
• The original Lithium blog tutorial.

The Basics

For the sakes of me being lazy, I’ll assume you have prior knowledge of:

• PHP 5.3 basics
• Another PHP framework (like CakePHP, the most popular PHP framework).
• Using GIT (you should have it installed, Ubunty folks: $ sudo apt-get install git-core)
• You should have an account setup with your SSH key in rad-dev.org (instructions here)

Adding PHP 5.3 support

There are many ways people have shown how to enable PHP 5.3 support on your servers. In my case, since I run my own compiled version of Apache + PHP, it gets easier. I’ll show you here how to set up dual support (PHP 5.2 and PHP 5.3) on your Apache in case you are as smart as me, and decided to build it yourself as well ;-]

First download and compile PHP 5.3 (this instructions point to the latest release of PHP 5.3 at the time of this writing, you may need to check PHP.net to see if there’s a newer version):

$ cd /usr/local/src
$ sudo wget http://ar.php.net/get/php-5.3.1.tar.gz/from/this/mirror
$ sudo tar xzvf php-5.3.1.tar.gz
$ sudo chown -R $USER:$USER php-5.3.1/
$ cd php-5.3.1/
$ ./configure \
  --prefix=/usr/local/php5.3 \
  --with-config-file-path=/usr/local/php5.3 \
  --with-libxml-dir=/usr/include/libxml2 \
  --with-mysql=/usr/local/mysql \
  --enable-pdo \
  --with-pdo-mysql=/usr/local/mysql \
  --with-zlib=/usr/local/zlib \
  --with-curl \
  --with-gd \
  --with-jpeg-dir=/usr/lib \
  --with-png-dir=/usr/lib \
  --with-freetype-dir=/usr/lib \
  --with-gettext \
  --enable-mbstring \
  --enable-soap \
  --enable-ftp \
  --with-openssl
$ make
$ sudo make install

Easy right? Now, whenever you want to add a virtual host that supports PHP 5.3, you’ll have to add these lines inside the <VirtualHost> directive:

ScriptAlias /cgi-bin/ /usr/local/php5.3/bin/
Action php53-cgi /cgi-bin/php-cgi
AddHandler php53-cgi .php5 .php

<Directory "/usr/local/php5.3/bin">
	Options +ExecCGI -Includes
	Order allow,deny
	Allow from all
</Directory>

Installing Lithium

First thing you’ll have to do is clone from lithium’s git repository. We’ll do it in a generic place, that we’ll be able to share from all our lithium applications, in order to keep up with the amazing ongoing development in Lithium. So let’s clone that stuff:

$ cd /var/www
$ git clone code@rad-dev.org:lithium.git lithium

So now in our /var/www/lithium directory we have lithium installed. Every time we’ll want to ugrade to lithium’s latest release, we’ll just do:

$ cd /var/www/lithium
$ git pull --rebase

Setup the application structure

We now have a generic place (/var/www/lithium) where we have lithium installed. Each time we start a new application, we’ll just copy over the application directory, and link to lithium’s core directory.

So we want to create an application in the host http://blog.li3 so we’ll store its files in /var/www/blog.li3. Let’s copy the files, and link to the core:

$ mkdir /var/www/blog.li3
$ cd /var/www/blog.li3
$ cp -pR /var/www/lithium/app .
$ ln -s /var/www/lithium/libraries libraries

Add the virtual host

Ok we now have the application installed in /var/www/blog.li3. Let’s create the virtual host for it. First edit your /etc/hosts file and add this line:

127.0.1.1	blog.li3

Now let’s add the virtual host to apache. Edit the file /usr/local/apache2/conf/extra/httpd-vhosts.conf (obviously this may be different in your setup) and add the following:

<VirtualHost *:80>
	ServerName blog.li3
	DocumentRoot "/var/www/blog.li3/app/webroot"
	ErrorLog "logs/blog.li3.error.log"
	CustomLog "logs/blog.li3.access.log" combined

	ScriptAlias /cgi-bin/ /usr/local/php5.3/bin/
	Action php53-cgi /cgi-bin/php-cgi
	AddHandler php53-cgi .php5 .php

	<Directory "/usr/local/php5.3/bin">
		Options +ExecCGI -Includes
		Order allow,deny
		Allow from all
	</Directory>
</VirtualHost>

You should now restart apache:

$ sudo /etc/init.d/apachectl restart

And you should be able to browse to http://blog.li3 and see a screen just like this:

Lithium's welcome screen

Install Doctrine 2.0

We’ll install doctrine as a system-wide library. Therefore we’ll move to our generic lithium install’s library path (/var/www/lithium/libraries) and download doctrine inside. Now we need the Doctrine ORM release (you may need to check the doctrine download page for a more up-to-date version of the 2.0 branch:

$ cd /var/www/lithium/libraries
$ mkdir doctrine
$ cd doctrine
$ wget http://www.doctrine-project.org/download/2_0_0_ALPHA3/format/tgz/package/ORM
$ tar -xzvf DoctrineORM-2.0.0-ALPHA3.tgz

Loading the Database

Now that we have the basics in place (PHP 5.3 enabled, Lithium installed, Doctrine installed), we’ll start building our application.

Creating the Database and loading some data

Let’s start by creating a database named blog_li3:

$ mysqladmin -uroot -p create blog_li3

Now load this SQL statements to the database we’ve just created:

CREATE TABLE `posts`(
    `id` INT NOT NULL AUTO_INCREMENT,
    `title` VARCHAR(255) NOT NULL,
    `body` TEXT NOT NULL,
    `published` BOOLEAN NOT NULL default FALSE,
    `created` DATETIME NOT NULL,
    `modified` DATETIME NOT NULL,
    PRIMARY KEY(`id`)
);

CREATE TABLE `comments`(
    `id` INT NOT NULL AUTO_INCREMENT,
    `post_id` INT NOT NULL,
    `name` VARCHAR(255) NOT NULL,
    `email` VARCHAR(255) NOT NULL,
    `body` TEXT NOT NULL,
    `created` DATETIME NOT NULL,
    `modified` DATETIME NOT NULL,
    PRIMARY KEY(`id`)
);

ALTER TABLE `comments`
    ADD KEY `post_id`(`post_id`),
    ADD CONSTRAINT `comments__posts` FOREIGN KEY (`post_id`) REFERENCES `posts`(`id`);

INSERT INTO `posts` VALUES
    (1, 'First post', 'This is the body for the first post', TRUE, NOW(), NOW());

INSERT INTO `comments` VALUES
    (1, 1, 'Mariano Iglesias', 'mariano@email.com', 'This is a nice post!', NOW(), NOW());

Setting up the DB connection

Let’s add the basics Doctrine needs to run into Lithium’s bootstrap. Edit the file app/config/bootstrap.php in your application directory (/var/www/blog.li3) and add the following at the end:

/**
 * Load Doctrine
 */

Libraries::add('Doctrine', array(
	'path' => LITHIUM_LIBRARY_PATH . '/doctrine/DoctrineORM-2.0.0/Doctrine'
));

Now how easy was that? Since Doctrine shares the same name structure Lithium does, the inclusion of Doctrine classes in Lithium is that easy. Next step: let’s set up the connection. Open app/config/connections.php and replace the whole Connections::add expression with the following (notice how we are adding a connection of type ‘doctrine’ rather than the default type ‘database’ lithium provides):

Connections::add('default', 'doctrine', array(
	'driver' => 'pdo_mysql',
	'host' => 'localhost',
	'user' => 'root',
	'password' => 'password',
	'dbname' => 'blog_li3'
));

Creating a wrapper for some Doctrine functionality

If you go through doctrine documentation, you’ll see it’s quite powerful and flexible. However, we’ll want to have a basic wrapper around the most common functionality (establishing the connection, querying a model, creating / editing / deleting records) so our work from our controllers is more transparent, and Doctrine agnostic. So let’s create a base class for all models (CakePHP folks, this will sound familiar) and name it AppModel

First, the code. Create a file named AppModel.php in your app/ directory, with the following contents.

<?php
namespace app;

use \lithium\data\Connections;

abstract class AppModel extends \lithium\data\model\Record {
	protected static $_alias;
	protected static $_entityManagers = array();

	public static function create($data = array()) {
		$class = get_called_class();
		$record = new $class();
		return $record->set($data);
	}

	public function set($data = array()){
		if (isset($data) && count($data) > 1) {
			if (!isset($data['created']) && !isset($data['id']) && !isset($this->id)) {
				$data['created'] = new \DateTime(date('Y-m-d H:i:s'));
			}

			if (!isset($data['modified'])) {
				$data['modified'] = new \DateTime(date('Y-m-d H:i:s'));
			}

			foreach($data as $key => $value) {
				$this->$key = $value;
			}
		}
		return $this;
	}

	public function save() {
		$entityManager = $this->_entityManager();
		$entityManager->persist($this);
		$entityManager->flush();
		return $this;
	}

	public function delete($id = null) {
		if (empty($id)) {
			$id = $this->id;
		}
		$entityManager = $this->_entityManager();
		$entityManager->remove($this);
		$entityManager->flush();
		return $this;
	}

	public static function find($type = 'first', $query = array()) {
		$class = get_called_class();
		$alias = self::$_alias ?: substr($class, strrpos($class, '\\') + 1);
		$methods = array('first', 'all');

		if (!in_array($type, $methods)) {
			throw new \Exception("Find method \"{$type}\" is not implemented");
		}

		$query = array_merge(array(
			'fields' => null,
			'conditions' => null,
			'order' => null
		), $query);

		$fields = array();
		if (isset($query['fields'])) {
			foreach($query['fields'] as $field) {
				$model = $alias;
				if (strpos($field, '.') === false) {
					list($model, $field) = explode('.', $field);
				}
			}
		} else {
			$fields[] = $alias;
		}

		$queryBuilder = self::_entityManager()->createQueryBuilder();
		$queryBuilder->add('select', $alias)->add('from', $queryBuilder->expr()->from($class, $alias));

		$expression = self::_conditionsToDqlExpr($alias, $queryBuilder, $query['conditions']);
		if (isset($expression)) {
			$queryBuilder->add('where', $expression);
		}

		if (!empty($query['order'])) {
			$order = $query['order'];
			if (is_array($query['order'])) {
				$order = array();
				foreach($query['order'] as $field => $direction) {
					if (!is_string($field)) {
						$field = $direction;
						$direction = 'asc';
					}
					$order[] = (strpos($field, '.') === false ? $alias . '.' : '') . $field . ' ' . $direction;
				}
				$order = implode(',', $order);
			}
			$queryBuilder->add('orderBy', $order);
		}

		$dql = $queryBuilder->getDql();
		$result = self::_entityManager()->createQuery($dql)->getResult();
		if (isset($result) && $type == 'first') {
			$result = current($result);
		}
		return $result;
	}

	protected static function _conditionsToDqlExpr($alias, $queryBuilder, $conditions) {
		$expr = $queryBuilder->expr();
		if (empty($conditions)) {
			return null;
		} else if (is_string($conditions)) {
			$expr = $expr->andx($conditions);
		} else {
			foreach($conditions as $key => $value) {
				if (is_string($key) && in_array(strtolower($key), array('and', 'or'))) {
					$clause = strtolower($key);
					$pieces = array();
					foreach((array) $value as $innerKey => $piece) {
						if (is_string($innerKey)) {
							$piece = array($innerKey => $piece);
						}
						$pieces[] = self::_conditionsToDqlExpr($alias, $queryBuilder, $piece);
					}
					$expr = call_user_func_array(array($expr, $clause . 'x'), $pieces);
				} else if (is_string($key)) {
					if (strpos($key, '.') === false) {
						$key = $alias . '.' . $key;
					}
					if (is_array($value)) {
						$values = $value;
						foreach($values as $iv => $value) {
							$values[$iv] = $expr->literal($value);
						}
						$expr = $expr->in($key, $values);
					} else {
						$expr = $expr->eq($key, $expr->literal($value));
					}
				} else {
					$expr = $expr->andx(self::_conditionsToDqlExpr($alias, $queryBuilder, $value));
				}
			}
		}

		return $expr;
	}

	protected static function _entityManager($connectionName = 'default') {
		if (!isset(self::$_entityManagers[$connectionName])) {
			$connection = Connections::get($connectionName, array('config'=>true));
			if (!isset($connection)) {
				throw new \Exception("Configuration {$connectionName} not found");
			} else if ($connection['type'] != 'doctrine') {
				throw new \Exception("Configuration {$connectionName} is not a doctrine configuration");
			}

			$config = new \Doctrine\ORM\Configuration();
			$config->setProxyDir(LITHIUM_APP_PATH . '/models');
			$config->setProxyNamespace('app\models');

			self::$_entityManagers[$connectionName] = \Doctrine\ORM\EntityManager::create($connection, $config);
		}
		return self::$_entityManagers[$connectionName];
	}

	/**
	 * Overrides for lithium/data/model/Record
	 */

	public function exists() {
		return !empty($this->id);
	}

	public function __get($name) {
		return isset($this->$name) ? $this->$name : null;
	}
}

?>

That’s a lot, right? First of all, this is generic enough so we won’t go through the detailed explanation line by line, but we’ll go through what each method does, and why is there. So let’s see:

• create(): creates a new instance of a record class, loading it with the specified data.
• set(): sets the specified data on the current record instance
• save(): saves (persists) the current record
• delete(): deletes the current record, or the record whose ID is specified
• find(): it finds :-] It tries to mimic the same parameters CakePHP has on its find method. Takes two parameters: first, the find type (only ‘first’ and ‘all’ supported here), and second an array of options (supported options: ‘fields’, ‘conditions’, ‘order’)
• _conditionsToDqlExpr(): helper method used by find() to convert the array based conditions into a Doctrine DQL Query (using Doctrine’s QueryBuilder)
• _entityManager(): gives back Doctrine’s EntityManager used to perform actual operations
• exists(): Tells if current record exists. Overriden from Lithium’s record to add support for the record in the FormHelper
• __get(): Gives back the given field’s value for current record. Overriden from Lithium’s record to add support for the record in the FormHelper

The models

Ok now to the fun part, creating the models our application will need. If you remember, the SQL script created two tables: posts and comments. Therefore we’ll have two models, Post and Comment. In order to link each comment’s property to a real table field, we’ll use Doctrine’s annotations. They define the characteristics of each record field through source code comments.

Let’s first create the Post model. Create a file named Post.php in your app/models folder with the following contents:

<?php
namespace app\models;

/**
 * @Entity
 * @Table(name="posts")
 */
class Post extends \app\AppModel {
	/**
	 * @Id @Column(type="integer")
	 * @GeneratedValue(strategy="AUTO")
	 */
	public $id;

	/** @Column(type="string") */
	public $title;

	/** @Column(type="text") */
	public $body;

	/** @Column(type="datetime") */
	public $created;

	/** @Column(type="datetime") */
	public $modified;

	/** @OneToMany(targetEntity="Comment", mappedBy="post", cascade={"remove"}) */
	public $comments;
}
?>

To understand the actual annotations, go through Doctrine’s introduction to docblock annotations. What it’s important for us is seeing that we have a property for each field in our posts table (what we want mapped to our record class), plus a property to store all related comments (the $comments property), each of which will be an instance of the Comment class.

So what about the Comment class? Create a file named Comment.php in your app/models folder with the following contents:

<?php
namespace app\models;

/**
 * @Entity
 * @Table(name="comments")
 */
class Comment extends \app\AppModel {
	/**
	 * @Id @Column(type="integer")
	 * @GeneratedValue(strategy="AUTO")
	 */
	public $id;

	/** @Column(type="string") */
	public $name;

	/** @Column(type="string") */
	public $email;

	/** @Column(type="text") */
	public $body;

	/** @Column(type="datetime") */
	public $created;

	/** @Column(type="datetime") */
	public $modified;

	/**
	 * @ManyToOne(targetEntity="Post")
	 * @JoinColumn(name="post_id", referencedColumnName="id")
	 */
	public $post;
}
?>

Just as before, we have a property per field, plus a property named $post to hold the instance of the Post a Comment belongs to.

The Controllers

Let’s first create the basic controller for Post records, that will simply show the list of post titles, with links for operations that we don’t yet have (editing, adding, removing, etc.) Create a file named PostsController.php in your app/controllers folder with the following contents.

<?php
namespace app\controllers;

use app\models\Post;

class PostsController extends \lithium\action\Controller {
	public function index() {
		$posts = Post::find('all');
		$this->set(compact('posts'));
	}
}
?>

That’s a very simple controller, isn’t it? We just get the posts, and pass it to the view as a $posts variable. So let’s create the view then. Create a folder named posts in your app/views/ folder, and then create a file named index.html.php in the newly created app/views/posts folder with the following contents:

<h1>Posts</h1>
<p><?php echo $this->html->link('Add new Post', '/posts/edit'); ?></p>
<ul>
<?php foreach($posts as $post) { ?>
	<li>
		<?php echo $this->html->link($post->title, '/posts/view/' . $post->id); ?>
		[<?php echo $this->html->link('Edit', '/posts/edit/' . $post->id); ?>]
		[<?php echo $this->html->link('Delete', '/posts/delete/' . $post->id, array('onClick'=>'return confirm("Are you sure you want to delete this record");')); ?>]
	</li>
<?php } ?>
</ul>

This code also speaks for itself. So let’s now create an action to view an actual post. Add a method named view() in your PostsController with the following code:

public function view($id = null) {
	$id = $id ?: $this->request->id;
	$post = Post::find('first', array('conditions' => compact('id')));
	$this->set(compact('post'));
}

We are basically getting the ID first (since it’s a numeric ID, a convenient Lithium route check will set it as part of the request information), and then looking for a Post with the given ID. That post will also contain the comments attached to it, so knowing that we can create the view for this action. Create a file named view.html.php in your app/views/posts folder with the following contents:

<h1><?php echo $post->title; ?></h1>
<p><small><?php echo $post->created->format('F d, Y H:i'); ?></small></p>
<?php echo $post->body; ?>

<?php if (!$post->comments->isEmpty()) { ?>
	<h3>Comments</h3>
	<?php foreach($post->comments as $comment) { ?>
			<p><small>
			by <a href="mailto:<?php echo $comment->email; ?>"><?php echo $comment->name; ?></a>
			on <?php echo $comment->created->format('F d, Y H:i'); ?>
			</small></p>
			<?php echo $comment->body; ?>
	<?php } ?>
<?php } ?>

<h3>Add your Comment</h3>
<?php echo $this->form->create(null, array('url'=>array('controller'=>'comments', 'action'=>'add'))); ?>
	<?php echo $this->form->hidden('post_id', array('value' => $post->id)); ?>
	<label>Your email:</label> <?php echo $this->form->text('email', array('size'=>60)); ?>
	<label>Your name:</label> <?php echo $this->form->text('name', array('size'=>60)); ?>
	<label>Comment:</label> <?php echo $this->form->textarea('body', array('rows'=>5, 'cols'=>60)); ?>
	<?php echo $this->form->submit('Add Comment'); ?>
<?php echo $this->form->end(); ?>

This code should also speak for itself, except probably the isEmpty() method, which is part of the collection’s methods Doctrine provides.

Another thing to note in the above view is the form at the bottom, used to add comments to a post. First thing we notice there is that we are setting as action for the post an action called add in a controller named Comments. We don’t yet have this controller, do we? So let’s add it.

Create a file named CommentsController.php in your app/controllers folder with the following contents:

<?php
namespace app\controllers;

use app\models\Post;
use app\models\Comment;

class CommentsController extends \lithium\action\Controller {
	public function add() {
		if (empty($this->request->data)) {
			$this->redirect('/');
		}

		$post = Post::find('first', array(
			'conditions'=>array('Post.id' => $this->request->data['post_id'])
		));
		if (!$post) {
			throw new \Exception("No post found for ID {$this->request->data['post_id']}");
		}

		$comment = Comment::create($this->request->data);
		$comment->post = $post;
		$comment->save();

		$this->redirect('/posts/view/' . $post->id);
	}
}
?>

This action looks more involved. First thing we do, is make sure someone is posting data to this action (that’s the check on $this->request->data, where the posted data comes in Lithium). If they don’t, we kick their butts. Next, we make sure there’s an actual post for the given ID. If there’s not, we throw an exception. The last part is the actual saving of the comment, so let’s go through that:

• With $comment = Comment::create($this->request->data); we create an instance of the Comment class, initially populating with the posted data (so the properties $email, $name, etc. will get populated with the posted data)
• Next with $comment->post = $post; we specify to which Post the Comment belongs to.
• Finally we persist (save) the Comment with $comment->save();

Since we redirect them no matter what, we need no view for this action. Also, you may have noticed that there’s no validation. That will be left as homework for you. After the comment is saved, we redirect the user back to the post page.

So we now know how to show the list of posts, how to view a post, and add a comment. All we have to do next is add the ability to add/edit posts, and remove them. Let’s start with the easy part, deleting a post. Add the following to your PostsController:

public function delete($id = null) {
	$id = $id ?: $this->request->id;
	if (!isset($id)) {
		$this->redirect('/posts');
	}

	$post = Post::find('first', array('conditions' => compact('id')));
	if (!$post) {
		throw new \Exception("No post found for ID {$id}");
	}

	$post->delete();
	$this->redirect('/posts');
}

This code almost needs no explaining after what we’ve seen so far. The only important part there is the actual deletion of the Post by calling its delete() method. Also, this is another action that needs no view, since we are redirecting them after the operation.

Finally, and since we have seen how to add a comment, adding a post won’t be that different. In fact, we’ll deal with adding and editing posts in the same action.

Add the following action to your PostsController:

public function edit($id = null) {
	$id = $id ?: $this->request->id;
	if (isset($id)) {
		$post = Post::find('first', array('conditions' => compact('id')));
		if (!$post) {
			throw new \Exception("No post found for ID {$id}");
		}
	} else {
		$post = Post::create();
	}

	if (!empty($this->request->data)) {
		$post->set($this->request->data)->save();
		if (!isset($id)) {
			$this->redirect('/posts');
		}
		$this->redirect('/posts/view/' . $post->id);
	}
	$this->set(compact('post'));
}

The important thing to notice here is that if there’s an ID provided, we try to get the Post. If there’s none, we create a new Post record instance by calling Post::create();. Then, once we got submitted data, we simply populate the properties with posted data and save the record, all in a single line: $post->set($this->request->data)->save();. Yeah, there’s no validation here either. More homework!

So what about the view for this action? Create a file named edit.html.php in your app/views/posts folder with the following contents:

<h3>Edit Post</h3>
<?php echo $this->form->create($post, array('url'=>'/posts/edit/' . $post->id, 'method'=>'post')); ?>
	<label>Title:</label> <?php echo $this->form->text('title', array('size'=>60)); ?>
	<label>Body:</label> <?php echo $this->form->textarea('body', array('rows'=>5, 'cols'=>60)); ?>
	<?php echo $this->form->submit('Add Comment'); ?>
<?php echo $this->form->end(); ?>

This is yet another code that speaks for itself. How lazy am I?

Conclusion

We’ve had fun, didn’t we? We now have a very basic blog system working, using PHP 5.3 only tools (Lithium, the most rad framework, and Doctrine 2, a very interesting ORM). We could easily extend this further, but we’ll wait on the work the Lithium team is doing to offer a much better integration with Doctrine. In the meantime, use this knowledge to have some fun, and build some cool projects!

No related posts.

I’m not gonna go through custom find types, you can find more info about them at Matt’s blog, or at this article written by someone whose name I think I’ve heard somewhere. What I’m going to talk about is how to mix your custom find types with pagination, without having to use paginate and paginateCount in your models.

So let’s first start by building yet another posts table, and inserting some records:

CREATE TABLE `posts`(
	`id` INT NOT NULL AUTO_INCREMENT,
	`title` VARCHAR(255) NOT NULL,
	`body` TEXT NOT NULL,
	`published` TINYINT(1) NOT NULL default 0,
	`created` DATETIME,
	`modified` DATETIME,
	PRIMARY KEY(`id`)
);

INSERT INTO `posts`(`title`, `body`, `published`, `created`, `modified`) VALUES
	('Post 1', 'Body for Post 1', 1, NOW(), NOW()),
	('Post 2', 'Body for Post 2', 0, NOW(), NOW()),
	('Post 3', 'Body for Post 3', 0, NOW(), NOW()),
	('Post 4', 'Body for Post 4', 1, NOW(), NOW()),
	('Post 5', 'Body for Post 5', 1, NOW(), NOW()),
	('Post 6', 'Body for Post 6', 0, NOW(), NOW()),
	('Post 7', 'Body for Post 7', 1, NOW(), NOW()),
	('Post 8', 'Body for Post 8', 1, NOW(), NOW()),
	('Post 9', 'Body for Post 9', 1, NOW(), NOW());

Now let’s assume we want a find type called published to fetch only the published posts, and that we also want to be able to paginate using this find type. We will be approaching this through a generic approach, something that can be used throughout all our models. With this in mind, let’s first introduce a model based member variable called $_types, where we define the specific needs of each custom find type. Therefore, that variable will hold what we need as conditions, order, etc. for each custom find type. So let’s build our Post model:

<?php
class Post extends AppModel {
	public $name = 'Post';
	protected $_types = array(
		'published' => array(
			'conditions' => array('Post.published' => 1),
			'order' => array('Post.created' => 'desc')
		)
	);
}
?>

As you can see, we define options for each find type as if we would be calling find() directly. So with the above, instead of doing:

$posts = $this->Post->find('all', array(
	'conditions' => array('Post.published' => 1),
	'order' => array('Post.created' => 'desc')
));

We can now do:

$posts = $this->Post->find('published');

Now, what if we wanted to paginate with the above custom find type? Just as we set pagination parameters through the controller member variable $paginate, we can specify which find type pagination we’ll use. We do so by specifying the find type in the index 0 of the pagination settings. Like so:

$this->paginate['Post'] = array(
	'published',
	'limit' => 10
);

$posts = $this->paginate('Post');

Easy, huh? When this is specified, paginate() does the following:

1. It issues a find('count') on the Post model, specifying the custom find type (published) in the $options array, through an option named type. Therefore, we can use $options['type'] when our model is about to do the count to use the given options for our custom find type.
2. It fetches the records by calling find() with the custom find type, find('published') in our example.

So where’s that sexy code? Add the following in your AppModel, making the above available for all our models.

<?php
class AppModel extends Model {
	public function find($type, $options = array()) {
		if (!empty($this->_types)) {
			$types = array_keys($this->_types);
			$type = (is_string($type) ? $type : null);
			if (!empty($type)) {
				if (($type == 'count' && !empty($options['type']) && in_array($options['type'], $types)) || in_array($type, $types)) {
					$options = Set::merge(
						$this->_types[($type == 'count' ? $options['type'] : $type)],
						array_diff_key($options, array('type'=>true))
					);
				}
				if (in_array($type, $types)) {
					$type = (!empty($this->_types[$type]['type']) ? $this->_types[$type]['type'] : 'all');
				}
			}
		}
		return parent::find($type, $options);
	}
}
?>

Now ain’t CakePHP great? Don’t tell me, tell everyone at CakeFest #3.

No related posts.

What better place to talk CakePHP than the world’s beer nation? That was the question that made the CakePHP Team decide CakeFest third edition should be located in Berlin, Germany. Just as Buenos Aires was the meat fest, I hereby predict that this will be the Beer Fest.

Let’s face it, your code gets better when you use CakePHP. So attending the official CakePHP gathering where all Core Developers and prominent community members go to share their knowledge is an offer you should not ignore. Add awesome beer and guaranteed fun to that recipe, and you would be insane not to join us.

So what are you waiting for? Go and get your CakeFest ticket as soon as possible, you don’t want to be left behind! If you have a company, or you are a regular Baker just wanting to show your love back to the project, do not hesitate to sign up for the sponsorship packages. Also help us spread the word by placing these CakeFest badges in your site, and you may even get a free ticket!

No related posts.

<?php
function format($size) {
	$unit = 'B';
	$units = array(
		'GB' => 1024 * 1024 * 1024
		, 'MB' => 1024 * 1024
		, 'KB' => 1024
	);

	foreach($units as $currentUnit => $value) {
		if ($size > 2 * $value) {
			$size /= $value;
			$unit = $currentUnit;
			break;
		}
	}

	return number_format($size, 1) . ' ' . $unit;
}

$settings = array(
	'host' => 'localhost'
	, 'user' => 'root'
	, 'password' => 'password'
);

$databases = array();

mysql_connect($settings['host'], $settings['user'], $settings['password']);

$result = mysql_query('show databases');
while($row = mysql_fetch_array($result)) {
	$databases[] = $row['Database'];
}

foreach($databases as $database) {
	$sizes[$database] = 0;

	mysql_select_db($database);
	$result = mysql_query('show table status');
	while($row = mysql_fetch_array($result)) {
		$sizes[$database] += $row['Data_length'] + $row['Index_length'];
	}
}

mysql_close();

foreach($sizes as $database => $size) {
	echo $database . ' = ' . format($size) . '<br />';
}

echo '<br />TOTAL: ' . format(array_sum($sizes));

?>

When I ran it, I saw all my DBs where taking a total of 10.8 GB, much less than the 86 GB occupied in the partition. So it hit me, it has to be the binary logs, a set of files that store log events (more about them here). Indeed, if you would list the contents of /var/lib/mysql I would find a ton of .bin files, a lot of them as old as from 2007. Therefore, I realized I had to flush the logs.

In order to flush the binary logs, I logged in to the MySQL console as an administrator, and issued (if you are on a server with replication, you want to purge the binary logs instead):

FLUSH LOGS;
RESET MASTER;

After doing so, the MySQL partition is now taking a total of 12 GB. Much better!

No related posts.

I am not even close to finishing it, but so far I’m having LOTS of fun. What is amazing is that missing only the M in MVC (the database abstraction layer), CLAPP’s performance is already astonishing. Running as FastCGI, it outperforms the most basic PHP file by a ratio of 1000%. Amazing.

So what am I looking to gain from this? Nothing, just having fun going back to my absolute favourite language: C++. In the meantime, I get to play with speed comparisons, which gets particularly interesting as I enable more stuff in the framework. My ideal goal is to include a lot of the you-just-have-to-have-this kind of things available on real, serious frameworks such as CakePHP. This doesn’t mean that I will hereon start developing every web application in C++, that would just be dumb (if you are asking why, then that’s because you haven’t given CakePHP a try). It does mean, however, that I’ll be posting about CLAPP every now and then.

To calm your expectations, here’s a very, VERY small preview of the Dispatcher, which is directly attached to every controller:

#ifndef __CLAPP_DISPATCHER_HPP
#define __CLAPP_DISPATCHER_HPP

#include <clapp/cgi_stream.h>
#include <clapp/controller.h>

namespace clapp {
	template <class C>
	class Dispatcher {
		public:
			Dispatcher();
			~Dispatcher();
			void dispatch();

		private:
#ifdef CLAPP_WITH_FASTCGI
			CgiStreamFastCgi * cgiStream;
#else
			CgiStream * cgiStream;
#endif

			void execute();
	};
}

template <class C>
clapp::Dispatcher<C>::Dispatcher() {
#ifdef CLAPP_WITH_FASTCGI
	this->cgiStream = new CgiStreamFastCgi();
#else
	this->cgiStream = new CgiStream();
#endif
}

template <class C>
clapp::Dispatcher<C>::~Dispatcher() {
	delete this->cgiStream;
}

template <class C>
void clapp::Dispatcher<C>::dispatch() {
#ifdef CLAPP_WITH_FASTCGI
	FCGX_Request request;

	FCGX_Init();
	FCGX_InitRequest(&request, 0, 0);

	while (FCGX_Accept_r(&request) == 0) {
		this->cgiStream->setRequest(request);
		this->execute();
		FCGX_Finish_r(&request);
	}
#else
	this->execute();
#endif
}

template <class C>
void clapp::Dispatcher<C>::execute() {
	C *controller = NULL;

	try {
		controller = new C();

		controller->setStream(this->cgiStream);
		controller->dispatch();

		delete controller;
	} catch(...) {
		if (controller != NULL) {
			delete controller;
		}
		throw;
	}
}

#endif

As you can guess from the source code, CLAPP can produce FastCGIs and regular CGIs. It uses ClearSilver for its view / layout templates, the FastCGI development kit (when FastCGI mode is enabled), and GNU cgicc as a CGI / FastCGI input wrapper. More news coming soon!

No related posts.