Code and Whatnot

I must say: I’m impressed. Starting with the tutorial, I’ve been familiarizing myself with the Django framework for Python. In some ways, Django closely resembles popular MVC frameworks such a Ruby on Rails and CakePHP. However, Django is the only web framework (whether it’s MVC is up-for-debate and not worth discussing) that hits what I’ll call the ’sweet spot’ between doing everything a framework should do, and staying out of your way. Rails, despite its own claims of ’staying out of the way’, really likes to make you a sandwich.

I won’t even go into a comparison with CakePHP, Zend Framework, or .Net, because none of them treat query result sets as nicely as Rails and Django; instead, I’ll just breeze through a quick and only partly educated comparison with Rails.

Working in Django has the deliberate feel of home-cooking, with a speed & instant-gratification quotient similar to the more automat-like Rails. Generally speaking, you edit files, reload your browser, edit more files, reload your browser, etc. You don’t run a lot of code-generating scripts, and Django is not the dictator of your schema. Early in the process, you can just delete your database and have Django generate a new one as you schema evolves. While Django will add new columns and tables for you, it will never screw with existing entities. I see this as a Good Thing. Schema updates should become infrequent fairly early in a project, and tend to require semi-manual roll-out in production environments.

The default template system mirrors the beautiful simplicity of Python. View methods (analogous to Rails controller methods) call templates directly by filename. Templates, rather then relying on heavy nesting or repetition, extend other templates — just like subclasses extend parent classes. The brutal efficiency of the Form class means that virtually every node in an instance of Form is printable. If you print the whole instance, you get a generic form. If you print form.fieldname, you get a field or a group of fields appropriate for the datatype of fieldname (assuming you have generated your form object from a model). You can also print form.fieldname.label, form.fieldname.id, form.fieldname.label.id, etc. This may sound confusing, but the result is that you can start with a boilerplate form and use the same object as you enhance and customize your form in future iterations. It brings a tear to my eye…

And that’s really all I have to say about my Django experience so far. I love its simplicity, the consistency of its interfaces, and the general ethic of solid architecture and unobtrusive beauty

I’ve gotten wrapped up in a few CakePHP projects lately. One thing that’s been bothering me is the confused notion of an instance of a model.

A CakePHP model is really a static entity: the constructor of User (User will be my example model) never returns an object with user data. Find, save, validate, and update operations all take user data as parameters. In fact, the only non-static property of note is the ‘id’ property, which essentially refers to the last record id that instance had to deal with. The ‘id’ property is generally only useful to find out the id of a newly inserted record. Something similar could be achieved by returning the inserted ID from the save() method or even setting a ’static’ class variable. That would be OK in PHP, since the class scope only extends as far as the current request. Because nothing is declared static, you need to instantiate the models. Minor refactoring could obviate the need to create instances.

In general, users (or, broadly, records from the table associated with a model) are dealt with as elements in a result set array/hash, returned from a Find method. I personally wish the elements of the array were instances of User, and that the User model had a real reason not to be static.

As it stands, the the static-ness of CakePHP models leads to very procedural-feeling code. All of this can be overridden, of course, but then it wouldn’t be a CakePHP model anymore; I try not to cut too deep into frameworks, as it will confuse new developers on a project. If CakePHP was old, I’d blame it on PHP 4. But CakePHP is new enough that there isn’t any reason why it couldn’t have a more object-oriented feel. In the meantime, CakePHP should fess up to the static-ness of its models and the documentation should explain them as such.