What I mean by “modular”

I’m putting my series on hold for a little while, as there’s been some recent chatter about a project I’ve been working on, django-modular, and I thought I’d try to write it up properly for the first time.

It’s a very cool app, and I think it could do wonders for Django-powered sites of all shapes and sizes (as long as app developers get on-board), but it doesn’t do anybody any good if nobody understands it, and the code doesn’t have all the features it needs.

The feature problem is one of my main concerns this week, but first I’d like to set the record straight as far as what it is, what it does, and why it’s important.

What the heck is “modular”?

I really struggled with the name for this app. Most generic Django apps are named for either an action they perform or for the types of objects they provide. This app would easily fit into the latter category, but “modules” already have a specific meaning in Python, so that wasn’t a valid option.

Instead, I had to go with the adjective, “modular”, to describe the type of sites it’s intended to facilitate. It’s not my first choice, but if you hate it too much, blame Guido for not letting me use “modules”.

Anyway, to define it, I typically point at commonly known homepage portals, such as My Yahoo! and iGoogle, but those aren’t entirely accurate. There are many similarities, but some important differences as well.

On one hand, they both break apart the content of the site into individual modules. Each module is its own functionality, set apart from all the other modules. A user can select multiple copies of modules and customize them to their own needs. That’s about where the similarities end, however. Those portal-centric sites are designed to pull in modules from a variety of sources, few of which are related to the site the modules can be found on.

Contrarily, django-modular is intended to build modules that are tied to a site’s content, and be embedded directly within that site’s look and feel. They’re not able to be pulled into generic homepage tools. But, they’re also much easier to create, design and implement.

I’ve documented most of what the app covers so far, but there’s more to come this week. I’m also sure I’m missing important things, so I’ll probably write about it again tomorrow night.

TODO

It’s getting late, so I don’t pretend this is a full set of features, but here are the biggest things I’m planning to get working this week:

• Ability to select which modules are actually available for use
• Better declaration of default modules
• Caching of full output or just the get_context() output
• Ability to restrict modules to anonymous or authenticated users
• Possibly allowing context processors to run for module templates (not sure about that yet)
• Ability to position modules, both user-backed and default varieties
• Possibly expand positioning to allow for more flexible layouts