My Django blogging app, django-nomadblog, is sporting a new look after I added many features I needed for some of my present and future project developments. Mainly, I wanted to turn this app into a multiple blogging system, which means I am able to create and manage multiple blogs from the same installation, via admin interface. The implementation of this followed some improvements in the code and the modularity of the app itself.
During this past week I have been attending DjangoCon, which took place in Berlin thanks to the German Django Association, a non-profit organization founded by german djangonauts. Interesting talks about Django, WSGI, NoSQL, testing, CouchDB, MongoDB, South or front-end design, to name a few. And in the evening or night, geeks gathered in Berlin pubs for beers and fun.
I came to a dirty but practical solution for one minor project I had to develop for a client who wanted a website with i18n capabilities and also needed to have the different translations for each candidate values each in a different field, in the same model. That is, one field for each language. Here in this post I explain how to achieve it.
Well it was time already to give some more code into the public domain and the community, so I decided to release my personal way of starting new django projects. I call it django-nbskel ("nb" for nomadblue and "skel" for skeleton).
It's been a month since the initial release of django-rbac and so far it turned out to be pretty useful for many people. I am therefore happy to have contributed another grain of sand to the open source Django community beach.
Many applications, and specially today's web applications -- which involve concepts as collaboration or content driven by the users -- need the flexibility to support delegation of permission granting to objects by other trusted agents. A clear example is a social networking site, where the users want to allow or deny access to their profiles or pictures, open or close their different communication channels like receiving friendship requests or private messages. django-rbac tries to champion this by introducing some key features from the Role-Based Access Control (RBAC) proposal. In this implementation users (subjects) are assigned different roles that, in turn, have (or not) privileges over objects. With this permission system, the owner of an object can give privileges to certain roles. For example, a user can grant access to other users trying to read some personal info only if they belong to, at least, one of the roles specified in the permission rule.
In a project with an application named concerts that lists concerts from european cities, consider a classic two-level URLconf where the root urls.py module "includes" (i.e. uses the include method from django.conf.urls.defaults) a second URLconf module.
DRY (Don't repeat yourself) is always a good coding practice I try to follow, at least whenever deadlines allow me to do so. Even for a bunch of code bits, it helps keeping clean and modular.
Talking about views, I find myself using different techniques and approaches to write a single function that centralizes all the logic and, at the same time, behave differently, depending on who is calling it.
This is a basic Django application implementing the most simplest form of a blog (from my point of view, of course). It has been written with an eye on keeping modularity as far as possible, so you won't find lots of goodies in the code, but just a couple of features to help you start hacking.
A whole weekend doing some fun coding has produced this brand new kid on the blogosphere. Soon I will write my first "real" post, in the meantime I can't wait to leave the URL to django-nomadblog, the django app that I built to run this weblog:
http://bitbucket.org/nabucosound/django-nomadblog
You will need Mercurial to clone it out. Hasta pronto!