avalonstar:distortion

It’s almost nauseating how many frameworks and blogging engines onecan choose today. Everything from Ruby on Rails, to SimpleLog and Mephisto, to CakePHP, Expression Engine, the growing Habari Project and even good ‘ol WordPress. All of these contenders (and the loads of others that I haven’t mentioned) have their appealing values, I had reasons, albeit small in most cases against using them. Note that I’ll be intentionally making general assumptions—each tool has their rightful place in different projects, just not in this “exploratory” one.

It wasn’t until I exchanged a few emails with Jeff that my outlook on what Avalonstar could possibly become blew open. WordPress, all of a sudden, felt so, confining. All of a sudden, I had so many ideas related to this blurry new vision. It didn’t have to be just a blog anymore. I could make it whatever I wanted it to be. I just needed to learn how.

The extent of my programming knowledge was PHP via my travels with WordPress. So obviously, if WordPress wasn’t going to be my choice anymore, I should have gone with one of the other structured blogging engines right? Well, no, and for a few reasons. The most common was, restriction, as I wasn’t going to leave WordPress for something that… basically worked like WordPress. So with all of the blogging engines out of the way, the only category left contained all of the frameworks.

The Organizational Value of a Framework

When I started planning in mid-April, I wanted to start by rethinking what I could classify as a blog post. More than anything, I had organization on my mind—or keeping fields as “semantic” as possible when related to the content that was to be placed in them. As you know, most blogging systems follow a basic model like this:

• Title
• Excerpt
• Post
• Taxonomy

Sure you could embed videos or different enclosures to vary the uses you’d get out of that model, but when it came to giving each type of post a different design, it didn’t seem very possible with a more structured system (do correct me if there is one that can do this effectively).

This is an early structure diagram for v24. It has since evolved from there to include completely different models for each type of post I plan on doing.

I wanted to be able to specify different models for each type of entry I’d end up writing, each with it’s own set of fields. Let’s jump straight to an example. Below is almost the exact model I’ll be using for when I start including video and screencasts as a part of Avalonstar’s entry routine.

class Videocast(models.Model):
    """
    A videocast contains an embedded movie and a trasncript, and thus is a video blog post.
    """
    
    # Meta
    author          = models.ForeignKey(User)
    headline        = models.CharField(maxlength=200)
    sub_title       = models.CharField(maxlength=250)
    slug            = models.SlugField(prepopulate_from=('headline',), unique_for_date='pub_date')
    # Categorization
    tags            = TagField()
    # Dates
    pub_date        = models.DateTimeField('Date Published')
    date_created    = models.DateTimeField(auto_now_add=True)
    date_updated    = models.DateTimeField(auto_now=True)
    # Content
    video_link      = models.URLField(verify_exists=True)
    video_download  = models.FileField(upload_to='/blog/video')
    transcript      = models.TextField()

You can see that it follows the same basic model, but is specific to this type of content. Each entry would still include the usual author, headline and subtitle. But it will also include fields for a transcript of the video, a field to input the URI of an embedded video (say from, Virb or Viddler) and a field to provide a downloadable version of the video. On top of this anal organizational routine, I would be able to specify a different template to customize the look. When I finally realized I had this flexibility, the possibilities were no longer restricted to the software and the plugins available for it.

The Sexy-ish Automatic Admin

Generating admin sites for your staff or clients to add, change and delete content is tedious work that doesn’t require much creativity. For that reason, Django entirely automates creation of admin interfaces for models.

Getting things “for free” is great for people who have no idea how to program. To be completely honest, this is one of the main reasons I started using Django over the other frameworks. I remember when I had first watched the famous Ruby on Rails “Create a weblog in 15 minutes” screencast, a good half of it is dedicated to the building the blog’s admin system, a very bare-bones admin system at that. Saving me from building the admin system incidentally saved me a lot of development time, and it’s a full-featured admin at that (well, as full-featured as your models get) which is easily extendable. The admin itself is also pretty sexy, but that’s what I say about all of Wilson’s work.

I guess a lot of this is what programmers would call “magic,” but I haven’t gotten that deep into any language to really mind it. :)

Now without Python! Well, not really.

I would classify the building of Avalonstar fitting the old 80/20 paradigm. Eighty percent of the work was completed in twenty percent of the time, and the final twenty percent took the remaining eighty. Other than learning to install Python, I didn’t have to learn much of it until I started creating definitions to make referencing data easier. Like, adding up all the steps in a specific workout or returning a certain string depending on whether variables existed or not. Python also started creeping up on me as I moved into working with views.

If you’re creating something simple, like a blog, with little or no programming knowledge, there are a hell of a lot of resources out there (including source code) to help you on your way. Something that did bother me, was that if you didn’t know how to work with the Python interpreter, a lot of the examples in the Django documentation would fly straight over your head (it all depends on how fast you learn). But again, you won’t be running into too much Python until you start moving into the views and eventually the deployment of your application.

The Templating System

Working with the Django templating system was a pleasant surprise. The whole {% block %} inheritance system proved to be a very powerful tool in not only creating dynamically generated pages, but dynamic “static” pages as well. Something that I loved when I first started out with WordPress was the fact that you had a header file, a footer file, and files for categories, an individual post and you could include each wherever you wanted (within reason of course). Django’s templating system takes that inheritance power a bit further, allowing you to extend any block you want to. A very simple example would be on my Dance Tracker, where I have the added copyright notice at the bottom. I’ll note that the copyright notice is included in the main template for the dance tracker and references an {% block extra-footer %} that I’ve defined in the main template.

Rather than violating Django’s DRY principle, I’ll leave the subject of template inheritance in the competent hands of a resident expert.

Wasn’t all blue skies and jazz music though.

I admit that I definitely ran into a lot of hard spots with Django, but Iwas able to find peace and a bit of happiness from working with the framework. The acts of deploying, having to configure Apache, mod_python, installing the numerous libraries proved to be the most nerve-racking. For being the second framework I’ve worked with (CakePHP, working with Snook, was the first), things could have gone a lot worse. But thankfully the community is very helpful and responsive. So even when I couldn’t bother Jeff, I could still find my answer fairly quickly.

I can definitely see myself building a few more applications with Django, and I look forward to chronicling that whenever that time comes.