Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django development on OS X using a local media server
Host static media from outside of Django while developing locally. For some, this solution will be rather obvious. For anyone else, I hope this helps your workflow like it helped mine. -
Django back on Dreamhost?
An email I received from Dreamhost indicated official support for running Django. After email correspondence with Dreamhost support, it's clear that Django is still not officially supported, but it should run better than it did before they made some recent changes. -
The basics of creating a tumblelog with Django (part 2)
Since posting "The basics of creating a tumblelog with Django," I've received some requests to explain how to get these tumblelog items to actually show up on my homepage. -
Working with the Django admin and legacy databases, pt.2
Working with the Django admin and legacy databases, pt.2 -
Image resizing on file uploads. Doing it the easy way.
Image resizing on file uploads. Doing it the easy way. -
Posting to the Twitter API on an admin change
Posting to the Twitter API on an admin change -
Working with the Django admin and legacy databases, pt.1
Working with the Django admin and legacy databases, pt.1 -
Working with the Django admin and legacy databases, pt.3
Working with the Django admin and legacy databases, pt.3 -
nabuco - Nomadblue Blog - First post
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! -
nabuco - Nomadblue Blog - django-nomadblog
Updated 13 Sep 2009: The current project page for django-nomadblog can be found here Here it is, the initial documentation for my first django app release, django-nomadblog. Overview 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. Features A mechanism to tell the application if there's gonna be only one blog or multiple blogs and users, easily configurable via a project setting and a URL pattern. Views are split into two functions, one for the view logic and the other in charge of creating or updating the RequestContext. This enables calling the logic behind a view without rendering the response. It is better explained below. Installation Soon I'll package the whole thing and upload it to PyPi for the sake of standard installations. Mercurial checkout Install Mercurial if you don't have it yet, and clone the repository: hg clone http://bitbucket.org/nabucosound/django-nomadblog/ Symlink to the folder called nomadblog inside django-nomadblog from somewhere in your PYTHONPATH … -
nabuco - Nomadblue Blog - Context in django views, DRY, reusable apps
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. Sometimes it is good to overload the number of arguments it receives, and use them as indicators and flags to switch to the desired behavior. A simple example, widely used in lots of Django apps and projects, is to pass a template variable from the kwargs positional argument in a URLconf: url( regex=r'^$', view='list_posts', name='list_posts', kwargs={'template': 'yourtemplatepath/templates/yourtemplate.html'}, ) In your view, you receive the parameter and render either the template value passed with the 'template' parameter, or the default template otherwise: def your_view(request, template='templates/default.html'): ... return render_to_response(template, {}, context_instance=RequestContext(request)) If you want to add functionality to certain cases, instead of modifying the base view, you better create a wrapper function, which will be called before, adding all the stuff you need to execute before or after. For instance, another trivial … -
django CMS 2.1 final was just released!
django CMS 2.1 final was just released! -
nabuco - Nomadblue Blog - Tweaking URLconf (2 named URLs, 1 view)
Introduction Update: I realized I didn't fully explained the whole picture of the issue I am describing here, so I have added a few lines more in the introduction section. 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. urls.py from django.conf.urls.defaults import * urlpatterns = patterns('', (r'^concerts/', include('concerts.urls')) ) concerts/urls.py from django.conf.urls.defaults import * urlpatterns = patterns('concerts.views', url(regex=r'^list/$', view='my_view', name='concerts_list_all') ) Let's say you want to extend the URLconf and have two kinds of URL to call the same view, the first to display all concerts, the second for concerts in a given city: /concerts/list/ /barcelona/concerts/list/ /london/concerts/list/ /paris/concerts/list/ There are two situations we want to overcome in this scenario. First, only one view must be used, so a little bit of business logic must be implemented. The function behaves differently if it receives the location keyword argument or not: concerts/views.py def my_view(request, location=None): if location is not None: # filter concerts QuerySet by location, for example else: # query all concerts return render_to_response('base.html', {'location': location}, context_instance=RequestContext(request)) The second one is the one … -
django-rbac
I just released my first version of a Role-Based Access Control system for permissions in Django. Development code can be found in BitBucket: http://bitbucket.org/nabucosound/django-rbac/ The project's page is here First of all, I would like to show some drawbacks of Django's current permission system: Permissions are tied directly to the User model from django.contrib.auth, so you cannot use any other existing model in your application. The task of mantaining this list of permissions in the current Django system is responsibility of a superuser or some other kind of centralized entity. You can certainly assign permissions to Group model instances, but all users in this group will share the same permissions. Last, but not least, until Django v1.2 will come and ticket #11010 implemented, the permission system is model-level -- it doesn't allow granular permissions (row-level), which means you can give a user authorization to do something based on all instances of a model class, but not to a single model instance (an object). 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 … -
Template tags in django-rbac
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. In Django, as in any MVC oriented framework, developers have to choose which side to put the logic on: a model method or function, inside a view or in a template tag. Although many recommend putting as little logic as possible in template tags, I know sometimes it is good to have one at hand to keep a healthy equilibrium, otherwise views can grow up fat or methods can spread like lemmings in your models and managers. I have recently added two template tags to django-rbac, to request for permission at model or object_level (RBACGenericPermission or RBACPermission, respectively). For example, a template rendering a profile page for a user can decide whether or not to show some personal information at rendering time, using the if_rbac_permission tag: {% if_rbac_permission owner model_inst operation roles %} <p>Pau Casals, 45 years old, male</p> {% else %} <p>You cannot view this information</p> {% endif_rbac_permission %} I updated the app documentation, there you can find … -
Dan Carroll | Blog | Setting up a cron job to run a Django management command in a Python virtualenv
-
django-nbskel
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). Development code can be found, along with my other apps, in Bitbucket: http://bitbucket.org/nabucosound/django-nbskel/ The project page is here. The purpose if this application is to contain a basic django project and help you out configure it to speed up the process of starting up a new development, be it a quick hack or a long project. I often need to produce new django projects and I don't enjoy doing repetitive things. They start basically with the same structure so with this app I can wrap all the first steps into a couple of actions. It also makes me feel secure because I always tend to forget to initialize settings, include files, import modules, and so on, so with django-nbskel I am sure I am beginning to develop upon a tested and stable code. Please be warned this is code that automates stuff for me, so you will be probably modifying it to fit your django configuration, tools, and deployment … -
Using InfinitePaginator to improve Django paging performance
One of my favorite Django projects is django-pagination. It provides some tools to make it incredibly easy to add paging support for long lists of objects. There are, however, a few considerations to make before using it in an application. Using it requires adding additional middleware, which imparts additional overhead to all of the requests and responses processed by a Django app. Also, in order to calculate the number of pages, django-pagination counts the number of rows in the model's table every time. While my site does not necessarily require screaming performance, I do like to squeeze as much out of my server as possible. For my paging needs, I do not need an exact count on the number of pages available. I provide a monthly archive on the site's sidebar, so for paging I only really care whether there is a previous or next page available. Using InfinitePaginator Luckily, django-pagination provides another option. I took the InfinitePaginator and InfinitePage classes from paginator.py. These allow for easy paging in the cases where it does not matter how many pages there are. To determine if there are any additional pages, it simply performs another SELECT query for one additional object past … -
Django translations for lazy programmers
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. Let's say we have some models with some fields we want to be duplicated, one for each language. In this example, we will store english (en), spanish (es) and french (fr): class MyObject(models.Model): name = models.CharField(max_length=50) title_en = models.CharField(max_length=50) title_es = models.CharField(max_length=100) title_fr = models.CharField(max_length=100) description_en = models.CharField(max_length=100) description_es = models.CharField(max_length=100) description_fr = models.CharField(max_length=100) class MyOtherObject(models.Model): name = models.CharField(max_length=50) content_en = models.CharField(max_length=200) content_es = models.CharField(max_length=200) content_fr = models.CharField(max_length=200) Notice we append a suffix to each field consisting of an underscore plus the language code. It is important to set the field names this way, as we are going to use a template tag that uses this suffix to find the proper translated field. Next thing to do is add a new TRANSLATION_FIELDS setting that will contain all the field names for ALL your model fields that … -
Extending and improving InfinitePaginator
In the previous entry, I explained how to use the InfinitePaginator class from the django-pagination project. I wanted that article to focus strictly on integrating the functionality into another application, leaving out the additional tweaks I had made. Setting up template context When it comes time to writing a template for a paged object list, there are numerous pieces of data needed: the objects on the page, whether there is a previous page, and whether there is a next page. We can get all of that information from the InfinitePage object in each view and manually add all of it to the template context, or we could directly access that data from the page object itself from the template. Personally, I wanted a consistent experience, so I added a helper method to the InfinitePage class. def create_template_context(self): return { 'object_list': self.object_list, 'has_next': self.has_next(), 'has_previous': self.has_previous(), 'next': self.next_link(), 'previous': self.previous_link(), } This function returns a dictionary with the contents of the page, boolean values specifying whether there are previous or next pages, and strings specifying the URLs to the previous and next pages. Then it is easy to call this function whenever you need to set up the template context: return … -
Setting up a Linux virtual machine for easy web development on Windows
Being a Windows user can be a real drag when trying to use technologies originally designed for the Unix world. This hardship is especially prominent in web development. While I do admire ASP.NET MVC, and enjoy being able to develop in C# as much as possible, my real passion right now is using Python with the Django framework. For simple applications, I often start out using Cygwin, the Django development server, and a sqlite database (side note: have you ever tried to get the MySQLdb library installed in Cygwin? What a mess!). But that setup can only take me so far. Not only is development a little tricky on a Windows box, but deployment and testing can be a mess. Most of the time, my web apps will be running on a Linux server. Ideally, I would be able to test everything locally in an environment as close to production as possible (and as a personal choice, without switching my development machine to run Linux). For a while, I tried to set up my Windows machine to run Apache and MySQL. That's fairly easy to do with something like XAMPP. The hard part is finding all of the necessary extensions … -
My thoughts on DjangoCon Berlin 2010
During this past week I attended 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 found a relief in meeting so many other people using Django, we djangonauts are a sort of lonely rangers here in Spain. The community is expanding, at the same pace that Django project is growing. In fact, it has already become a grown up in the open source ecosystem, and I think this fact is one of the main reasons that brought Jacob Kaplan-Moss give the first talk in the opening day about how we, Django users/developers/commiters, have to behave with the project itself and to the eyes of the others. The pony, a silly mascot that can be embarrassing to somebody (picture a girl asking her parents to buy her a pony, or a gay decorating his bedroom with stuffed animals, and you won't find the scene much related to guys with beards, pirates, ninjas or geeks hacking python) is precisely … -
Accessing and debugging the Django development server from another machine
In continuing my series about setting up a Linux virtual machine for Django development (see parts one and two), I wanted to share another tip for accessing the VM from the host machine. Set up development server to listen to external requests By default, when using the Django management runserver command, the development server will only listen to requests originating from the local machine (using the loopback address 127.0.0.1). Luckily, the runserver command accepts an IP address and port. Specifying 0.0.0.0 will allow the server to accept requests from any machine: python manage.py runserver 0.0.0.0:8000 I do not have to worry about security issues with the development server listening to all requests, since the VM is protected from external access by a firewall. Set up server to send debug information to local network While the first step will allow us to access the development server from the host machine, we will not be able to see debugging information (for example, the django-debug-toolbar will not be displayed on the host machine, even if DEBUG is set to True). Django uses another setting, INTERNAL_IPS, to determine which machines are allowed to view debugging information. For a typical installation, I set INTERNAL_IPS to … -
New release of django-nomadblog
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. To upgrade this django blog to the new version of django-nomadblog, I should have created a migration using South, for example. But considering the small size of the database and the project inn general, I went the lazy way and created a fixture from the old database, edited by hand to meet the new models and relationships, and imported it to a fresh database. My punishment for being lazy was missing to update django.contrib.sites to replace the default example.com with nomadblue.com, and to include the data related to the projects site section in the fixture. I'll never learn. -
LFS website goes online
It's done. The website is online. On this place we plan to publish information about LFS in short intervals. If you want to keep informed you can subscribe to our news feed and/or follow us with Twitter. If you have questions or suggestions please don't hesitate to contact the team behind LFS.