Introduction
Posted in Django
on February 19th, 2009 by
Stephen DeGrace
First of all, I want to say that I'm totally new to blogging, and new to Django. I mean, I rarely even read other people's blogs, even though I often enjoy it when I do, so I suppose I'm a hypocrite for hoping other people might read mine. When I decided that I wanted to build a new web site, and try blogging, one of the basic design decisions I made is that it would be composed of multiple blogs on a variety of topics, so that for example anyone who wanted to read my rants could avoid technical discussions, and vice versa. Hence this Django blog.
I'm assuming that people reading this know what Django and Python are.
I have been working on this web site since some time in November and I only just on Valentine's day finally went public, and it was only tonight that I put on what I consider to be the finishing touches of the basic design and content (since I had to see it live for a while to figure out some of what I wanted).
I spent a lot of time before that trying to decide on a framework to build this site. My previous site, which was down for a long time, was a home-rolled CMS written in PHP, and I didn't want to go there again. Python is my favorite language and always my language of choice for projects whenever possible, so I wanted to write something in Python, and I wanted to take advantage of one of the frameworks out there (check out the Ruby on Rails hype I guess).
I was immediately attracted to Turbogears. I was attracted to the Kid or Genshi templates which are valid XHTML, and the object publishing style of dispatch, plus the "best of breed" philosophy. I looked at Django too, but I was put off by the templates, and the way that the official version was apparently quite old and people were expected to work from the trunk. Despite the assurances, that freaked me out. I like to use official, stable versions of things.
So I spent a lot of time on Turbogears. The thing with Turbogears was that I think in all the months I toyed with it, I never managed to get beyond the initial Welcome to Turbogears new project page. I'm serious, I never got to the point of displaying my own content, although I did put together my models and a couple views. At first the problem was too much choice. I spent a huge amount of time researching all the components, and then considering alternatives to all the components... should I use the currently-supported SQLObject, or the ostensibly-supported but really not all that beginner friendly SQLAlchemy, which is fated to become the new TG default ORM. Should I use Kid or Genshi. Etc.
Then I started running into the paucity of good documentation. TG has really shitty documentation. (They say TG2 is much better). You get the neat little Wiki demo, which scratches the surface all too shallowly, and then you discover that you're on your own with the documentation for the individual components. Often the preffered TG idiom was considerably different from, for example, the docs for CherryPy, the TG controller, but the TG idioms are very sparsely documented. This made very slow going.
Finally, I got my shit tgether and started writing models. The default way to work in TG is that you cram all your models into a single file, all your controllers into a single file, etc., and if you use an extension like their Identity framework, those models have to get written into your megalithic models.py so you had better install that stuff before you start writing if you know what's good for you. I started turning all my attention to finding a way of hacking Turbogears so that you could devide your project into applications, each of which encapsulates some natural function and has its own models, controllers, templates, etc.
One day I posted on the turbogears Google group asking about how you could implement such a feature, and someone replied that it was just such a thing which attracted them to Django. I took a second look at Django and discovered that there was a 1.0 release. I decided that Django deserved a serious second look, and never looked back. You really do get used to the templates - the ability to extend the templating language makes Django templates much more forgivable, and the ability to use the templating system to generate arbitrary text actually comes in handy.
For fun, I am demonstrating here an example of how I have my gallery app integrated with all the others via django-tinymce and django-filebrowser... I just insert the photo from the appropriate directory, which I can browse with cute thumbs, apply the class I want, and set the title to {# imagebox #}... my imagebox filter finds these images and links them to the gallery app metadata.
I think the best thing about Django is that it is organized. You don't have to make giant hacks in order for your work to be organized - Django inherently wants you to organize your work and makes it easy for you to do so. Also, Django is very well documented. There is also a very active user community.
TG is a great project, but I think in the end it is just not for me and it will need to go a ways and get better documentation and a much more stable suite of default components before I would look at it again. I don't recommend it for beginners. I think it's more for people who are savvy to the world of Python web frameworks. For me, TG's single biggest flaw, though, is that they don't structure it in such a way as to make it obvious or natural to organize your work, which for complicated projects could become a problem.
The bottom line is that Django enabled me to get my work done, and in my opinion done well, and I'm totally over the issues that caused me to not be naturally attracted to it initially.
Anyway, I plan to start off my blogging career by posting about technical aspects of this site, My First Django Project.
I spent a long time on this site, and I think it came out pretty good, although I intend to tweak it quite a bit. Here's a basic list of features:
- Pretty much everything in the site can be access controlled by logged in status, Staff status, or membership in a list of allowed groups. That's how I decided I preferred to do access control.
- The main menu is a Django application editable from the Admin interface. Links can be hard coded, can be in a view/params form, or based on an object lookup, and can be access controled. They can go to arbitrary recursive depth, and a javascript on the front end turns them into popup menus out to arbitrary recursive depth. An Evil feature to be sure. People with Javascript turned off get a link to the Sitemap which is just the whole root menu as nested lists.
- The django-tinymce application is used in the admin site and on the front end (I like to do my actual blogging from the front end) for my own article writing. It is integrated with django-filebrowser for inserting images. It is also integrated with my gallery application.
- One-off and unique pages are handled through the page application. This gives tinymce editing for both the main and optional sidebar content, access controls, and membership in a Category, which can optionally auto-generate a menu for a sidbar. It includes a render_page.html template that uses my {% render %} template tage to allow content to contain Django template markup (but I don't usually use it because then I would have trouble blogging about Django templates).
- The blog application provides multiple blogs and access controls. Access controls are through the blog not the articles. Blogs have owner groups, members of which can create articles in the blog
- The gallery application provides photo galleries. Galleries can auto-discover when you dump photos in their directories, or manually delete photos, and create and remove Picture objects as needed. Pictures generate a variety scaled images, inclduing django-filebrowser thumbs.
- Site registration is protected by Recaptcha, through its Python bindings.
- You can email arbitrary users who allow it in their profile. Anonymous visitors have to solve a recaptcha to send mail.
- Comments are enabled, but I decided to make them available only to registered users, in the hope that that extra layer of difficulty might reduce comment spam. You can comment on Pages, Pictures and Articles. I don't provide anything like markdown for comments, God forbid TinyMCE. I really don't see the point, although maybe I'll change my mind.
- I created an application called pygmentation that provides filters to easily paste code into articles in TinyMCE and syntax highlight it with Pygments. BTW, Pygments Rocks!
- I added RSS support.
- I have a hitcounter app too. Hitcount is per session. BTW, the generated image looks a lot shitter with PIL on WebFaction compared to PIL at home, I have to sit down and figure out what gives soon.
- My common app, which contains the ancestors of most of my models, also has a really evil template tag library, including some little gems like {% render %}, {% bind %}, {% alias %} and {% ifcheck %}. I really love those last three. They're tools of the devil, of course, but I use them everywhere.
Anyway, I guess that's enough stuff for now... some time soon I plan to pick on some particular Django feature to discuss, hopefully using some experience I had writing this site as a jumping-off point.
Comments:
There are 0 comments on this item. Be the first to comment.
Post a Comment
* Required field, your email will not be posted.