For February I tinkered with Django, arguably the most popular web framework for Python. Prior to this, the only web framework I’ve had experience with is CodeIgniter and one proprietary JSP-based framework.
In an earlier post I covered installing Django. Nothing much has changed between then and now except that the most recent version of Django, 1.5, now supports Python 3! The first for Django ever. But I’m sticking with Python 2 for the time being.
Note: I tried learning Django last August, in an afterthought project with goals loftier than what my resources could have achieved. Needless to say, I never got too far with it. It was this which prompted me to specify a mini-project I’d use to learn web frameworks (any web framework). I’m not sharing the specifics of it now but you can gather what you can in my sandbox repository.
The Admin Site
One nifty feature of Django is how it creates an admin site automatically for you. On my CodeIgniter projects, I’d pattern the users table something like this, borrowing from Linux file systems:
CREATE TABLE IF NOT EXISTS users( -- Some project-specific fields here create_time TIMESTAMP NOT NULL, last_updater INTEGER NOT NULL, last_update TIMESTAMP NOT NULL, can_read BOOLEAN NOT NULL DEFAULT TRUE, can_write BOOLEAN NOT NULL DEFAULT TRUE, can_exec BOOLEAN NOT NULL DEFAULT FALSE, PRIMARY KEY (userid), FOREIGN KEY (last_updater) REFERENCES users (userid) -- Yes, apparently, MySQL allows you to foreign key recursively ); |
If I’m really feeling up to it, or if the project requires (never had it tho), I might even implement user groups. But even with this, I can already define 23=8 types of users, which is already way more than what one project usually requires. What I’d normally do here is to designate can_exec privileges to admins. Way neater than maintaining different tables for different user types and then giving admins backdoor log-in pages—one of the naive approaches I used when I first started designing databases for apps.
Django automatically covers this for you, user permissions, groups, and all. The structure becomes a bit different though, and I find permission management way more complicated than my binary-scheme. Take a look at all possible user permissions in Django:
Look at how many that is, and realize that there is still a scroll bar!
What Django basically did is to allow you to specify add/change/delete permissions for every table in your database. Note that due to how Django enforces code modularity (see below), the number of tables in your database could easily blow-up.
Code Modularity
Perhaps one of the most confusing things I encountered as I tried to learn Django was how it distinguishes the terms “project” and “app”. Normally, I’d talk about an “app” being a “project” for some party. But in Django a project is a collection of apps. I had a hard time designing my project around these terminologies even after reading discussions at StackOverflow until I realized that perhaps a better term for “app” would’ve been “plug-in” and there’s really nothing stopping you from making your project as one big plug-in.
With the side-effect, of course, of your app being non modular and probably not well-factored. So, yes, the way Django handles things enforces the nice practice of modularity. Nice to take advantage of it, though it may be too time-taking to wrap your design around Django’s rules.
Django also enforces a form of Object-Relational Mapping (ORM). In fact, you don’t need to write a single line of actual SQL code to get your database up and running—all DB creation is done through the ORM and manage.py . This even allows you to easily switch DB back-ends. Then again, as with above, not all projects would fit well for an ORM approach.
Overall?
I find Django pretty neat given that you only need minimal set-up for this whole bunch of admin stuff. But then I haven’t had much time to explore it although I’ve volunteered in a (non-work, non-paid) project that might use Django pretty extensively. Guess I’ll get more Django this month. Let’s see.