Coding My Thoughts A glimpse at a coder's troubled mind Wed, 27 Feb 2013 10:39:53 +0000 en-US hourly 1 http://wordpress.org/?v=3.6 PHP Conference Argentina /cakephp/php-conference-argentina/?utm_source=rss&utm_medium=rss&utm_campaign=php-conference-argentina /cakephp/php-conference-argentina/#comments Wed, 27 Feb 2013 10:39:08 +0000 mariano /?p=269 Related posts:
  1. Argentina on the Basketball World Championship
  2. First Google Analytics results for Java Users Group Argentina
  3. Argentina: 3.71 % of its population affected by traffic accidents every 10 years
]]>
I am co-organizing PHP Conference Argentina. Based on the impressive speaker lineup, and the community support we have received, I believe this conference will not only be a huge deal for Argentina, but for Latin America as a whole.

When and where?

It’s a two day conference, celebrated 4 and 5 of October. We chose Buenos Aires not only because it is the most popular tourist destination in South America, but because it is home of the most active startup scene in the region.

Where do I get my ticket?

Tickets are up for sale at awesome discounts. Go get yours before they are sold out!

Who’s coming?

Check the speaker lineup. In the meantime here are some of our speakers: Rasmus Lerdorf (creator of PHP), Igor Sysoev (creator of NGINX), Derick Rethans (creator of Xdebug), Brian Doll (VP of Marketing at GitHub), Daniel Rabinovich (CTO of MercadoLibre), Sebastian Bergmann (creator of PHPUnit), Benjamin Eberlei (lead of Doctrine2), Nate Abele (creator of Lithium), Jordi Boggiano (creator of Composer), and Pablo Godel (founder of ServerGroove).

Why is it a big deal?

2012 showed that Argentina was the right place to host IT events, fact confirmed by the success of both RubyConf AR and JSConf.ar. It only made sense to not only offer a bigger, more important event this year, but to target web development as a whole.

That’s right. You don’t have to be using PHP to enjoy PHP Conference Argentina. We will be offering general web development talks for every PHP talk, so this is an event you don’t want to miss!

]]>
/cakephp/php-conference-argentina/feed/ 1
Extracting g11n translation strings in Lithium /php/extracting-g11n-translation-strings-in-lithium/?utm_source=rss&utm_medium=rss&utm_campaign=extracting-g11n-translation-strings-in-lithium /php/extracting-g11n-translation-strings-in-lithium/#comments Sat, 26 May 2012 16:17:49 +0000 mariano /?p=264 Related posts:
  1. Persistent localized routes with Lithium
]]>
If you are like me, you are happy, and you use Lithium. If you are not like me, well then, it sucks to be you. I personally love the Lithium-Doctrine2 (by means of li3_doctrine2) combo. It suits my needs, and gives me peace of mind. Sort of like a good glass of scotch at the end of the day. I don’t drink scotch, by the way.

Anyway if you are aiming for dominating the world, you need internationalization in your app. It is quite easy to do so with lithium. Go check the documentation, I’m not here to teach you about it. What I am here to do is fill a gap in li3′s proposal for g11n: extracting your translation strings and putting them in a nice gettext POT, ready for translation. I’ve built a dead-simple python script that gets the job done. Call it with the typical help argument and you’ll get:

$ scripts/g11n.py --help
usage: g11n.py [-h] [-a APP] [-o OUTPUT_FILE]

Globalization extract

optional arguments:
  -h, --help            show this help message and exit
  -a APP, --app APP     Application directory
  -o OUTPUT_FILE, --output-file OUTPUT_FILE
                        Where to write template

So you basically specify it the application directory, and where to write the template file. It will go through your application directory (skipping only the resources/g11n/ and resources/tmp paths) looking for any PHP files, and extract the strings. However it does not come so easy. If you are using Lithium’s built in translation lambdas ($t and $tn in your views) it will not work. I personally set a couple of function aliases in my app/config/bootstrap/g11n.php file, so that I could use the same translation functions regardless if I’m on a view, a controller, entity, or whatever else. These two aliases look simple enough:

function _t($message, array $options = array()) {
	return \lithium\g11n\Message::translate($message, $options + array(
		'default' => $message
	));
}

function _tn($message1, $message2, $count, array $options = array()) {
	return \lithium\g11n\Message::translate($message1, $options + compact('count') + array(
		'default' => $count == 1 ? $message1 : $message2
	));
}

So if you start using the above _t() and _tn() functions you can use my python script. It uses a well established tool known as xgettext for helping out with the extraction, and msgmerge for merging. The script source code is:

#!/usr/bin/env python

import argparse, os, re, subprocess, sys, tempfile

if __name__ == '__main__':
	parser = argparse.ArgumentParser(description='Globalization extract')
	parser.add_argument('-a', '--app', default='app/', help='Application directory')
	parser.add_argument('-o', '--output-file', help='Where to write template')
	args = parser.parse_args()
	args.app = os.path.abspath(args.app)

	if not args.output_file:
		args.output_file = args.app + '/resources/g11n/default.pot'
	if not os.path.isdir(args.app) or not os.path.exists(args.app):
		print('{i} is not a valid directory'.format(i=args.app))
		sys.exit(1)

	print('Preparing to extract strings from {i} and store them in {o}'.format(
		i = args.app,
		o = args.output_file
	))

	dirs = os.listdir(args.app)
	skipPaths = [
		'resources/g11n',
		'resources/tmp'
	]
	count = 0
	o = tempfile.NamedTemporaryFile(delete=False)
	for root, dirs, files in os.walk(args.app, followlinks=True):
		d = re.sub(r'^' + re.escape(args.app + '/'), '', root)
		skip = False
		for skipPath in skipPaths:
			if re.match(r'^' + re.escape(skipPath) + '/?([^/]*)', d):
				skip = True
				break
		if not skip:
			for f in files:
				if re.search(r'' + re.escape('.php') + '$', f):
					o.write((os.path.join(root, f) + '\n').encode('utf-8'))
					count += 1
	o.close()

	print('Found {c} files to process'.format(c=count))

	if count > 0:
		output = args.output_file
		backup = None
		if os.path.exists(args.output_file):
			backup = args.output_file + '.old'
			output += '.new'
			os.rename(args.output_file, backup)

		subprocess.call([
			'xgettext',
			'--files-from=' + o.name,
			'--output=' + output,
			'--keyword',
			'--keyword=t',
			'--keyword=_t',
			'--keyword=tn:1,2',
			'--keyword=_tn:1,2',
			'--language=PHP',
			'--from-code=\'utf-8\'',
			'--package-name=\'workana\'',
			'--copyright-holder=\'Workana\'',
			'--package-version=\'1.0.0\'',
			'--msgid-bugs-address=\'g11n@workana.com\''
		], stdout=None, stderr=subprocess.STDOUT)

		if os.path.exists(output):
			newOutput = output + '.sed'
			with open(newOutput, 'w') as f:
				subprocess.call([
					'sed',
					's/\(Content-Type:\s*text\/plain;\s*charset=\)CHARSET/\\1UTF-8/i',
					output,
				], stdout=f, stderr=subprocess.STDOUT)
				if os.path.exists(newOutput):
					os.rename(newOutput, output)

		if backup:
			print('Merging with existing template')
			subprocess.call([
				'msgmerge',
				'-i',
				'-N',
				'-o',
				args.output_file,
				backup,
				output
			], stdout=None, stderr=subprocess.STDOUT)

			os.unlink(output)
			os.unlink(backup)
	os.unlink(o.name)
]]>
/php/extracting-g11n-translation-strings-in-lithium/feed/ 0
Persistent localized routes with Lithium /php/persistent-localized-routes-with-lithium/?utm_source=rss&utm_medium=rss&utm_campaign=persistent-localized-routes-with-lithium /php/persistent-localized-routes-with-lithium/#comments Sun, 11 Mar 2012 19:33:08 +0000 mariano /?p=252 Related posts:
  1. Route middleware with Lithium
]]>
Just a few minutes ago I got pinged through IRC asking if I could provide a quick answer. The question asked by m99 (thanks for the blog post inspiration!) was if there was an easy way to ensure localized routes with Lithium. As with any challenge you face with lithium, the answer ended up being dead simple.

So let’s make sure we understand what we want to do first by enumerating a list of objectives:

  • We want to make sure that our application URLs are prefixed with a locale that identifies the language, and region of choice.
  • If there is no locale in the URL, we need to figure out what the best choice is for the current visitor, and point them to the same URL they are intending to reach, but with the locale prefix added.
  • We want to make this prefix persistent (search engine mumble jumble.) So once a locale prefix is set, all links within the application should contain the prefix.

Believe it or not, all this is pretty much offered out-of-the-box using nothing but the following Lithium features

So let’s get to work. First thing we want to do is ensure that the g11n.php file is loaded as part of the bootstrap process. So edit your app/config/bootstrap.php file and uncomment the line that requires the app/config/bootstrap/g11n.php file.

Next we want to define which languages are supported in our application. Normally the list of supported languages is defined in the g11n.php file through environment variables, as you can then use that to build up a language menu in your views, or test more languages on different environments. Edit the languages defined in your app/config/bootstrap/g11n.php file. For example my list of languages looks like the following:

$locale = 'en_US';
$locales = array(
	'en_US' => 'English',
	'es_AR' => 'Español'
);

Environment::set('production', compact('locale', 'locales'));
Environment::set('development', compact('locale', 'locales'));
Environment::set('test', array('locale' => 'en', 'locales' => array('en' => 'English')));

Now we want to make sure we allow locales to be specified as part of an URL. Edit your app/config/routes.php file and add the following route right before any of your custom routes (so it should pretty much stand as the first route defined):

Router::connect('/{:locale:[a-z]{2}_[A-Z]{2}}/{:args}', array(), array('continue' => true, 'persist' => array('locale')));

We now need to make sure that if there is no locale specified, or if the locale is not valid, we prefix the current action with a valid locale. We also want to be smart and figure out what’s the best language for the current request, and if there is a language match, but not a region match, we still maintain their desired language (for example, in our g11n.php file we defined es_AR as the only spanish localization, so if someone with an es_ES locale shows up, we still want to take them to a Spanish version of our website.)

Go back to edit your app/config/bootstrap/g11n.php file, and look for a closure bound to a variable named $setLocale right at the very bottom. This closure normally looks concise, but replace it all with the following:

UPDATE: The best matching code that was taking care of our example es_ES -> es_AR matching scenario has been greatly simplified by the recent pull request merged into Lithium on 6c95cb80bc

$setLocale = function($self, $params, $chain) {
	$redirect = false;
	$locales = array_keys(Environment::get('locales'));
	if (!$params['request']->locale()) {
		$redirect = true;
		$locale = Locale::preferred($params['request'], $locales);
	} else {
		$locale = $params['request']->locale();
	}

	if (empty($locale) || !in_array($locale, $locales)) {
		$redirect = true;
		if (!empty($locale)) {
			try {
				$locale = Locale::lookup($locales, $locale);
			} catch(\InvalidArgumentException $e) {
				$locale = null;
			}
		} else {
			$locale = null;
		}

		if (empty($locale)) {
			$locale = Environment::get('locale');
		}
	}

	if ($redirect) {
		$params['request']->locale($locale);
		$url = compact('locale') + $params['request']->params;
		return function() use($url) {
			return new \lithium\action\Response(array(
				'location' => $url
			));
		};
	}

	Environment::set(true, array('locale' => $params['request']->locale()));
	return $chain->next($self, $params, $chain);
};

Let’s do a quick summary of what the code above does:

  • Lines 02-08: try to get the locale from the current prefix. If no prefix is provided, do it by figuring out what would be the best locale for the current request.
  • Lines 11-26: what to do if there is no locale (something is weird in the request and we can’t figure out the best locale for the client.), or if the locale specified is not within our list of active locales. The interesting part here are lines 13-21, where we do the best-match discovery I mentioned earlier. So if someone is requesting an en_UK locale, and we only have en_US, we make them use en_US. This block of code ends with a simple fail over: if no locale was found to be best for our client, we use the default locale (lines 23-25)
  • Lines 28-36: If we have figured a new locale, we redirect the user to the current URL, but setting the new locale.

That’s it! Try accessing your application with no locale defined. For example if you try to reach http://myapp/signup you will be redirected to http://myapp/en_US/signup, and all your links will be prefixed with the en_US.

]]>
/php/persistent-localized-routes-with-lithium/feed/ 2
Responsible buying /general/responsible-buying/?utm_source=rss&utm_medium=rss&utm_campaign=responsible-buying /general/responsible-buying/#comments Mon, 13 Feb 2012 19:28:54 +0000 mariano /?p=246 No related posts. ]]> You may be asking what prompted me to write about anything other than code (disregarding the fact that my last post was written quite a while ago.) Let me tell you. I often debate general issues on my twitter account (sometimes in english, sometimes in my mother tongue, spanish.) Some of these debates end up being quite productive, prompting me to further think about the discussion at hand, or to even change some of my behaviors.

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?

]]>
/general/responsible-buying/feed/ 1
Route middleware with Lithium /php/route-middleware-with-lithium/?utm_source=rss&utm_medium=rss&utm_campaign=route-middleware-with-lithium /php/route-middleware-with-lithium/#comments Tue, 03 Jan 2012 16:03:51 +0000 mariano /?p=232 Related posts:
  1. Persistent localized routes with Lithium
]]>
I spend most of my day switching between languages. Sometimes I start the morning with an early dose of LUA, then I get a lot of Python and C++, followed by the yummy dessert that is Node.js. But there’s always room for PHP. So let’s talk about PHP today.

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. :)

]]>
/php/route-middleware-with-lithium/feed/ 3
Book release: CakePHP 1.3 Application Development Cookbook /cakephp/book-release-cakephp-application-development-cookbook/?utm_source=rss&utm_medium=rss&utm_campaign=book-release-cakephp-application-development-cookbook /cakephp/book-release-cakephp-application-development-cookbook/#comments Wed, 30 Mar 2011 22:49:58 +0000 mariano /?p=221 No related posts. ]]> Just a few days ago, I was happy to see my first book published. Entitled CakePHP 1.3 Application Development Cookbook, it’s a book released in the form of a cookbook, with a series of solutions to common problems one faces when developing CakePHP applications.

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.

]]>
/cakephp/book-release-cakephp-application-development-cookbook/feed/ 17
File uploading with multi part encoding using Twisted /python/file-uploading-with-multi-part-encoding-using-twisted/?utm_source=rss&utm_medium=rss&utm_campaign=file-uploading-with-multi-part-encoding-using-twisted /python/file-uploading-with-multi-part-encoding-using-twisted/#comments Fri, 20 Aug 2010 03:14:04 +0000 mariano /?p=209 No related posts. ]]> If you program in Python and you are building web clients you need to know about Twisted. It is perhaps the most flexible and powerful Python framework for building web clients and servers, and has been proven to work wonderfully under heavy loads. So powerful, that the most basic tasks tend to be a bit of a pain. This is what I realized when I found myself in the need to upload large files to a web site using Twisted. I googled, and I googled, and I found no real answer to my problems.

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?

]]>
/python/file-uploading-with-multi-part-encoding-using-twisted/feed/ 4
Building a blog with Lithium and Doctrine /li3-lithium/building-a-blog-with-lithium-and-doctrine/?utm_source=rss&utm_medium=rss&utm_campaign=building-a-blog-with-lithium-and-doctrine /li3-lithium/building-a-blog-with-lithium-and-doctrine/#comments Sat, 02 Jan 2010 21:47:38 +0000 mariano /?p=137 No related posts. ]]> This post aims to be a very basic introduction to the world of Lithium, also known as li3. As such, it is mostly based on the ubiquitous blog sample. The idea is to learn, through the source code, the basic notions on Lithium and its integration with the Doctrine ORM mapper to build a very basic blog application. Unlike the blog example at rad-dev.org, this example is based on Doctrine 2.0, which is (at the time of this writing) in Alpha stage, and is built for PHP 5.3. After this tutorial, you should be able to jump start and build your own li3 powered applications.

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:

The Basics

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

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!

]]>
/li3-lithium/building-a-blog-with-lithium-and-doctrine/feed/ 9
Pagination with custom find types in CakePHP /cakephp/pagination-with-custom-find-types-in-cakephp/?utm_source=rss&utm_medium=rss&utm_campaign=pagination-with-custom-find-types-in-cakephp /cakephp/pagination-with-custom-find-types-in-cakephp/#comments Tue, 28 Apr 2009 15:11:00 +0000 mariano /1/pagination-with-custom-find-types-in-cakephp/ No related posts. ]]> With the release of CakePHP 1.2 a whole set of new features were made available to us bakers. One of those features is custom find types, which is one of the coolest things that ever happened since I realized I was cooler than Maverick.

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.

]]>
/cakephp/pagination-with-custom-find-types-in-cakephp/feed/ 11
CakeFest #3: CakePHP in Berlin, July 9-12 /cakephp/cakefest-3-cakephp-in-berlin-july-9-12/?utm_source=rss&utm_medium=rss&utm_campaign=cakefest-3-cakephp-in-berlin-july-9-12 /cakephp/cakefest-3-cakephp-in-berlin-july-9-12/#comments Mon, 23 Mar 2009 16:53:00 +0000 mariano /1/cakefest-3-cakephp-in-berlin-july-9-12/ 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!

]]>
/cakephp/cakefest-3-cakephp-in-berlin-july-9-12/feed/ 0