Naming conventions thoughts for Pinax and Django

I really like Pinax. As the core framework behind our NASA HQ open source social networking application Spacebook, it has been a literal godsend. Out of the box it met most of our requirements, and the Pinax team has graciously added many of our needs to the feature set of Pinax going forward (div based forms, for example). My opinion is that Pinax is a great demonstration of what you can do using Python, Django, and an open source community. We'll be using it for Spacebook and other projects moving forward.

However, if there is one thing I could improve in Pinax (and Django), would be its adherence to a model naming standard. Yes, it does follow the Django convention of naming models, but it doesn't have any internal conventions beyond the Django convention.

Whatever do I mean?

Well, lets say I want a single report to display all the bookmarks and blogs I've added in the last 2 hours, and include the name and description of each item. In theory, via the ORM, I can simply query both via user as a related field, write a django template to display the data, plug in a url, and then I'm done.

That is the theory.

However, the problem is that the Bookmark model has description and note fields, and the Blog model has title and tease fields. To make this more clear, let me demonstrate what I get:

1. BOOKMARK: description/note
2. BLOG: title/tease

So now either my template or my view has to account for different naming conventions per type. Yes, I know that django templates will not display absent variables, but what if I need to add a third model that follows yet a different convention? Or a fifth? Or a sixth? What if I want to write some awesome introspection engine to creatively fetch and list titles and descriptions of the records? Oops - now I have to carefully catalog each type or queryset I'm going to receive. Testing will have to account for lots of use cases. My code is now more complex. Heavier. Slower.

I'm having to configure, rather than follow convention.

A proposed solution

Its all about convention over configuration.

Years ago in the dark ages of the late 1990s or early 2000s, a bunch of librarians got together and established the Dublin Core for content. Everything had a title and description field, not to mention optional body, author and other useful fields that could with every bit of content.

I propose this solution for Pinax (and Django) as a standard for items that represent text based editable content. So maybe not for financial/sports numbers, but instead for blogs, bookmarks, wiki pages, projects, groups, tribes, articles, and all that other bit of stuff that we like to read.

So if I do a query that returns Bookmarks and Blogs, all I need to care about is the convention of using titles and descriptions, not checking the model to see if my understanding of its configuration (name, tease, note, rant, description, intro, etc) is correct.

Pretty neat!

And yes, those of you from the Plone/Zope communities will find this very familiar.

Spacebook ITCD demo a success!

Yesterday Katie Cunningham presented on Web 2.0 and our latest implementation, Spacebook at the ITCD NASA HQ event. As always, she nailed the presentation, and handled the questions with skill and grace. Before and after the presentation we demonstrated live Spacebook at our booth. People seemed very interested, and we became skilled and hooking people into Spacebook.

I received the chance to proselytize on the benefits we had from using the Free and Open Source Software community to accelerate our development. We would not have been able to demonstrate a stable, working application without the contribution of the Pinax team. The amount of support we received from them was incredible. In fact, our requirements are helping to drive the growth of Pinax, and thanks to us they will be US Government Section 508 compliant.

Should django-uni-form handle boilerplate HTML?

This is in regards to my django-uni-form project, which lets you do proper fieldset forms in Django, letting you do prettily formatted forms that meet the Section 508 specification, not to mention various accessibility and usability guidelines.

Basically, I think django-uni-form could be a little more helpful. So what do I mean?

Standard uni-form looks like:

<form class="login uniForm" method="POST" action="">
<fieldset class="inlineLabels">
<legend>* Required fields</legend>        
  <div class="ctrlHolder ">     
    <label for="id_username"> * User Name</label>
    <input id="id_username" type="text" name="username" maxlength="30" />
  </div>
</legend>
</fieldset>
<div class="buttonHolder">
          <button type="reset" class="resetButton">Reset</button>
          <button type="submit" class="primaryAction">Submit</button>
        </div>
</form>

django-uni-form gives just:

  <div class="ctrlHolder ">     
    <label for="id_username"> * User Name</label>
    <input id="id_username" type="text" name="username" maxlength="30" />
  </div>

Does it make sense for django-uni-form to provide the following?

<fieldset class="inlineLabels">
<legend>* Required fields</legend>        
  <div class="ctrlHolder ">     
    <label for="id_username"> * User Name</label>
    <input id="id_username" type="text" name="username" maxlength="30" />
  </div>
</legend>
</fieldset>

With this, you can still add in buttons elegantly. Thoughts?

Update: I'm working with James Tauber and perhaps some others to figure out the best way to make this work.

Tell me your Plone blogging tool preferences

I have a new internal facing Plone project here at NASA. One of my requirements is to have a blog system. So this is your chance to suggest to me your favorite blogging tool. Want to see some requirements? Sure!

• Must work in Plone 3.1.x+.
• Groups will have blogs.
• Users will be in possibly multiple groups.
  
• Any user in a group can post a blog entry.
• Output must be Section 508 compliant.

What do I want to see in a blogging tool as a developer?

• Easy to implement.
• Clean code base so it will be easy to migrate to future versions of Plone.

Update: Thanks to the comments, for now I am going with Scrawl. It meets my formal requirements handily, and also meets my personal preferences. If the scope of the blog grows I will explore other options.