Maneater/Django development lessons, Part 2

Through a series of posts, I’m counting down to a public test of the new Maneater Web site by the end of the weekend. We’re hoping to launch Tuesday.

In the first part, I introduced the project and talked about the history. This is part two.

This is mostly a technical writeup. For those that aren't programmers, the final post (Part 4) is a general "layman's terms" overview of new features on the site.


Square One

In late December, frustrated with a poor development workflow in Drupal, I mulled it over with Carolina Astrain (our online editor) and decided to go back to Django. I did this on the condition that I could fashion a functional demo in four days or go back to the Drupal project. I promised to have the site (regardless of platform) done by February. A big dare on my part, but necessary in my book: I needed hard deadlines for results. This was getting done whether I liked the workflow or not.

Over the course of hosting switches for the Django and Drupal projects, all of the old code from the prior Django project was lost. But this didn't really matter because Django -- still in development -- had gone through several major revisions and backwards-incompatible changes from the version Chase and Brian had worked on.

Again, this was fine because the site barely worked in that incarnation -- we nearly rewrote it from the ground up at one point, until the project stagnated.

So, I started the arduous task of creating a full-fledged news outlet Web site from nothing. Did I mention that I didn't know Python and that I was in way too deep the last time I worked on the old Django project? Yes, I was learning this on the fly. (I actually wish I hadn't lost Chase and Brian's code; I did not understand a bit of it back when I was responsible for it, but I believe I could learn a lot from that now.)

Django is a framework -- not so much as a "program everything" programming language as much as a programming language that does a lot of your workflow for you. Having such a versatile framework environment is probably the only reason I was able to do this with such little help.


And we're off

Django uses a "design pattern" (workflow) that is split up into three "layers". Most frameworks are. Django uses a very pure three-tier method: model, view, template. Or in layman's terms: what sort of information you have in your database, the logic that determines what stuff to get from your database and processes it, and the templates that take that "view" and turn it into pages, feeds, and other files. (For those programmers that know of the "Model-View-Controller" pattern, the "view" represents your controller in doing the logic, and the "template" represents your view.)

I think it's a nice system, because you can delegate your tasks based on those layers and so long as your team members know what to expect from people working on another "layer", they don't need to know the innards of the other layers.

But of course, I'm working on this more or less on my own (save for some templating help from Justin Myers) so that layer separation doesn't necessarily save me except for the fact that it's really well-suited for learning on the fly. Think about it: instead of worrying about every aspect of a site at once (overload!), you can focus on and learn specifically how to model your data and finish that, focus on how to create views for your data and then finish that, and then learn the nitty-gritty on templating.

Let me tell you one thing, though: Frameworks like this are designed to be quick-to-build. It's a framework, in literal terms, where you build off of a mostly prefabricated structure. I can imagine designing fast workflows around this, with the ability to churn out very diverse applications (don't just copy and paste the same code between projects) at the drop of a hat. I'd be happy to learn a few other frameworks and use another MVC/MTV pattern in the future.


Next Top Model

The beauty of a framework like Django is the data modeling features. If you've used an entity-relationship diagram (ERD), you already know more about this than is necesary. If you can list out the types of metadata for something...

  • Issue
    • Volume (Integer)
    • Date (Date)
  • Staffer
    • First Name (Text)
    • Last Name (Text)
    • Position (Text)
  • Article
    • Title (Text)
    • Date (Date)
    • Issue (Issue)
    • Section (Text)
    • C-Deck (Text)
    • Byline (Staffers)
    • Body (Text)
  • Photo
    • Date (Date)
    • Byline (Staffer)
    • Photo (Image)
    • Cutline (Text)
  • more or less already have your database set up and an admin interface automatically made for you. This example is a gross simplification of the Maneater's basic data models. (If you're really interested in learning what models look like in code, see the Django Book.)

    The best part about Django's data models is fields that represent images you upload (for photos and graphics) and regular files you upload (for PDF pages and podcast audio files). The admin panel automatically takes care of uploading files to a folder you specify.

    That example admin interface uses different example data, but visually it's the same admin panel the new Maneater site uses. And I'm assuming that the Columbia Missourian and Vox Magazine admin interface probably looks the same too.

    The automatic admin interface is one of the single most important features of Django. Believe me, it takes forever to program your own way of adding, modifying, and removing stuff from a custom database.

    Taking that CS 3380 database class at the same time as this project also propelled me along quite a bit. I cannot stress enough the importance of good, connected data models, and that class is where I got it pounded into my skull. Of all the things in the Django framework, your data models really can't be edited after the fact without massive pain -- i.e. manually editing your database. It's better to have more metadata than you need than to realize later that you left out some information.

    Create a very full outline of the things you plan on putting into the site and every bit of information that goes under them. I don't think I could start a major project in any language without doing that sort of visualization now.


    Of course, data modeling and having an admin interface doesn't give you a site that's browsable.

    Next: "Views" and templating.