A Django application design puzzle about modularity

June 21, 2013

As I mentioned in passing yesterday, we need a web-based email settings control panel for our users, something that allows them to set various options for their account in more user-friendly ways than editing their .forward files or logging in to our Unix machines to run scripts. The natural way for me to put this together is to use Django, since I've been happy with our other Django-based web application.

But this now leaves me with a design puzzle. We'd really like this email settings control panel to be 'modular' in the sense that we can easily add more settings to it over time, exposed through some UI and the like (in fact it's pretty much a requirement that it be modular this way). However it's not clear to me how to structure this in Django, either in the project structure or in the database. The most obvious setup for code modularity probably wants each separate module of options to be a separate web page on a distinct URL. This is simple to implement but kind of a terrible user experience (and it results in a proliferation of database tables).

A more elaborate version would embed all of the forms on the same web page, probably manipulating various sorts of form visibility and form submission through JavaScript for a better user experience. But that feels like it's going to require a bunch of hacking, likely embeds knowledge of all of the modules (and all of the active modules for a given user) into the page's template, and so on.

Finally there's a less Django-native version of modularity where the overall form presented to users is not a representation of a model. Instead we'd some database of settings (probably very abstracted) and the form code would basically do manual mapping between the database and what the user saw. We'd have our own plugin system so that a setting 'module' could define its settings, how to represent them in a form, and so on. However theoretically right this sounds the drawback here is that is that I'd be writing a lot of code and designing completely custom systems.

(I could even throw out Django in favour of a simpler web framework system, which makes it clear how far out this approach is.)

I don't have any answers to this puzzle right now because I've only just started really thinking about it. It's quite possible that Django has some clever way of doing or supporting this that I haven't run into yet, or that there's a common design pattern in the Django community for handling this issue.

(I certainly hope that there turns out to be an obvious and simple way to do this inside Django; it'd make my life simpler. While one part of me wouldn't mind diving head-first into building my own modularity framework, another part of me wants to get this project done in a sane amount of time.)

Written on 21 June 2013.
« The question of whether to rewrite an old but working service
Automatedly overwriting changed files is not a feature »

Page tools: View Source, Add Comment.
Search:
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Fri Jun 21 01:48:49 2013
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.