February 3, 2008 – 1:15 pm
I’m typically a PHP guy. I wrote my first web page using PHP3 and have created some pretty robust websites since then and for the most part it’s been a pleasure to work with. I also have a bit of experience using Zend Framework which among other things has a really strong MVC implementation, but I can’t help but feel a bit left behind when I look at features of some other modern frameworks. I’ve been playing around with Django for a few days and a few things have occurred to me.
Validation logic should be part of the model
Take a look at this bit of code from Django.
1
2
3
4
5
6
| # in visitor/models.py
class Visitor(models.Model):
name = models.CharField(maxlength=30)
email = models.EmailField(maxlength=200,blank=true)
website = models.URLField()
donated = models.DecimalField(max_digits=5, decimal_places=2, blank=true) |
In the Zend_Validator is much more complex, typically happens in the controller and has no direct relationship with the data model your validating for.
1
2
3
4
5
6
7
8
9
10
11
12
13
| $nameValidator = new Zend_Validate_StringLength(1,30);
$emailValidator = new Zend_Validate();
$emailValidator->addValidator(new Zend_Validate_StringLength(0, 200))
->addValidator(new Zend_Validate_EmailAddress());
// Zend doesn't have a URL validation class, so we would have to
// create a custom validator that extends Zend_Validate
$website = new Custom_Validator();
// This only validates that the number is a floating point number,
// in reality we would probably have to write another custom validator
// to validate monetary values.
$donated = new Zend_Validate_Float(); |
The nice thing about Django is the actual database tables are created from the model. So when you declare a name field with the maxlength of 30, your validation rules knows your fields max length because it’s based from the same one line of code the database field was created from! I’m not sure I believe building database tables from your model code is the only way to do things, but I am sure complex validation logic for models belongs in their implementation, not in the controller.
Template inheritance rocks.
This is sadly something I had never seen before. Instead of having half a dozen include statements in each of your views you can just have on that says that it extends your base template. The nice thing about this is the child view/template can override what ever portions of the base template it wants, or it can just go with what the parent has. Django’s documentation has a really good example of template inheritance in action.
An auto generated admin interface is more valuable than gold.
Before playing with Django I watched a few screen casts to get a feel for what it was all about. Then Django seemed like a one trick pony to me and the one trick seemed a bit lame. I mean, auto generated administration interface… who cares. Since then I’ve learned Django certainly has more than one trick up it’s sleeve and their main act is really beautiful in person. It is honestly as robust (or more so) as any administration interface I’ve built in the past. I expected something clunky and extremely _not_ user friendly. I really expected it to generate an admin interface that made it somewhat more convenient for programmers, but wouldn’t work for the average Joe. Well, when they say it’s “production ready” that’s exactly what they mean. The number of hours this saves (that can be spent developing fun stuff) is extremely valuable.
Admin scripts
I know this will sound a bit lazy, but I don’t like having to manually create half a dozen empty folders every time I set up a new project, controller etc. Rails and Django both do a good job of generating framework skeletons for you so you can plug away without missing a beat.
Shell to poke at objects
This is really a language feature and not a framework feature, but you can do some really sexy stuff inside the Django shell like insert a new visitor:
>>> p = Visitor(name="Steven", website="http://steven.bitsetters.com")
>>> p.save()
Or select the last five blog posts
>>> recent = BlogPosts.all()[:5]
This makes it possible to stay in Python land forever if you wish. No bouncing around between SQL and Python.
Built-in development servers make getting started fun
There is nothing like spending half an hour setting up Apache and mod_* before writing your first line of code. Django and Rails bundle a lightweight web server who’s sole purpose is to make development easy and convenient. Unfortunately you won’t be seeing a bundled PHP based web server with your favorite PHP framework anytime soon. Try writing one and see how far you get without things like thread support. PHP is really more of a template language itself than a general purpose programming language. Projects like PHP-GTK make me giggle. Single threaded GUI applications are awsome! </sarcasm>
Posted in Django, Php, Programming, Python, Zend Framework | 2 Comments »
