Writing section revisited 11.05.2007

Several weeks back, I realized that whilst my initial implementation of the writing center was wonderful in its automation, it was also incredibly inflexible. Things were rooted to a specific layout and structure without an easy way to modify anything.

As such, tonight I finally had time to sit down and revamp the entire writing system. The resulting framework is generic enough to encompass things like a review section or anything else that’s hierarchical in nature. It allows dynamic typing of pages to access specific templates, and it allows parent-child relationships to be changed on the fly depending on foreignkeys.

The Admin Screen:

Admin screen

There are two main objects in the writing section, with room for more as needed. Currently, they are: Page and Type.

The Page

The building block of the new system is the Page. A Page is simply a single URL destination — be it /writing/ or /writing/nanowrimo/ or, in the future, /review/apple/iphone. Each Page object carries with it some properties:

  • A parent property assigns a place in the hierarchy, all stemming from a single root page that has no parent. Otherwise, all other pages have a parent. As an example, both /writing/ and /review/ would have no parent, whereas its immediate children would have itself as their parent.

  • A Title

  • A URL, that’s user definable. This is initially linked to the title via Django’s auto-filling slug. But it can also be changed manually. I changed it manually at /writing/nanowrimo so that the slug wasn’t the default National-Novel-Writing-Month. Each Page’s URL defines it’s own URL segment. So the NaNoWriMo page defines ‘nanowrimo’ and the NaNoWriMo 2007 page defines ‘2007’. Following the child->parent associations will give /writing/nanowrimo/2007.

  • Various other things like body text, summary text, headings, titles, etc.

  • Type. This determines the type of layout this Page uses.

In the future, this will probably also hold ratings, and some other specific review section properties.

Here’s a shot of the Page screen:

Page screen

And this is what it looks like when editing a page:

Page edit screen

The Type

Type screen

Each type carries with it a path to the specific template that I want to use for that page. In the future, this may also hold some dynamically linked objects that the page in question should include.

In my “NaNoWriMo Directory” type, for example, it links to a template that displays the word count progress meter at the top.

I’m also giving specific Types more objects to work with in the specific Page view. So for example, the “NaNoWriMo Directory” type mentioned above also has word count and percentage_completed variables that are passed to the template.

The end result of this new Page/Type system is that I can easily prune and rearrange branches as I see fit, and very quickly change the entire organization of the section by reassigning a few parents.