Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django Patterns: Pluggable Backends
As the first installment in a series on common patterns in Django development, I'd like to discuss the Pluggable Backend pattern. The pattern addresses the common problem of providing extensible support for multiple implementations of a lower-level function, for example caching, database querying, etc. Problem The use of this pattern often coincides with places where the application needs to be configurable to use one of many possible solutions, as in the case of database engine support. Consider the following: The application needs to support Backend A and Backend B but if you look closely at the methods exposed there are some discrepancies: Backend A has slightly more verbose method names than Backend B Backend B does not accept a default value on the get() method In Django we see this pattern all over the place: django.contrib.auth django.contrib.messages django.contrib.sessions django.core.cache django.core.files.storage django.core.mail django.core.serializers django.db Analysis Here is a first stab at getting our Application to talk to backend A and B: class ApplicationBackend(object): def __init__(self, backend): # here we are self.backend = backend def get(self, key, default=None): if isinstance(self.backend, BackendA): return self.backend.get_data(key, default) elif isinstance(self.backend, BackendB): try: return self.backend.get(key) except BackendB.KeyError: return default def set(self, key, value): ... etc ... Notice … -
Django Patterns: Pluggable Backends
As the first installment in a series on common patterns in Django development, I'd like to discuss the Pluggable Backend pattern. The pattern addresses the common problem of providing extensible support for multiple implementations of a lower-level function, for example caching, database querying, etc. Problem The use of this pattern often coincides with places where the application needs to be configurable to use one of many possible solutions, as in the case of database engine support. Consider the following: The application needs to support Backend A and Backend B but if you look closely at the methods exposed there are some discrepancies: Backend A has slightly more verbose method names than Backend B Backend B does not accept a default value on the get() method In Django we see this pattern all over the place: django.contrib.auth django.contrib.messages django.contrib.sessions django.core.cache django.core.files.storage django.core.mail django.core.serializers django.db Analysis Here is a first stab at getting our Application to talk to backend A and B: class ApplicationBackend(object): def __init__(self, backend): # here we are self.backend = backend def get(self, key, default=None): if isinstance(self.backend, BackendA): return self.backend.get_data(key, default) elif isinstance(self.backend, BackendB): try: return self.backend.get(key) except BackendB.KeyError: return default def set(self, key, value): ... etc ... Notice … -
Booktools
A little-known bit of trivia about our book, Python Web Development with Django: we wrote the manuscript in Markdown. I think it was my idea. One of the major motivations for using a text-based format -- versus the unfortunate de facto standard, Microsoft Word -- was integration with good developer tools and workflow. Our manuscript and all our project code was in a Subversion repo, so each author always had the latest updates. HTML generated from the Markdown files was great for generating nice printed/printable output too. We could have used any number of similar formats: Markdown, Textile, reStructuredText. If we did it again we'd probably use reST plus Sphinx. That would grant all the same advantages, plus give us a little more formatting flexibility and tool support. This workflow enabled certain kinds of programmatic action on our text, notably two things: automated testing of the interactive examples within the text, and automated extraction of example snippets from source code files. I wrote scripts for each of these tasks. I've cleaned them up a little, to try to make them a little more general-purpose, and published them (with minimal example files) in a bitbucket repo: http://bitbucket.org/pbx/booktools There's a little documentation … -
Django on uWSGI and Nginx
I recently moved Pegasus News from Perlbal, Lighttpd, and Apache to Nginx and uWSGI. We balance the traffic between 3 physical servers, and the systems were struggling under the load even after weeks of Apache conf tweaking. We began having issues with excessively slow page loads, request timeouts, and intermittent errors with OGR transformations. I decided to move us to a lighter application server so that we could get the most out of our system resources, and after a lot of research and testing I chose uWSGI. While I was at it, I decided to replace Perlbal and Lighttpd with Nginx because of its great configuration syntax and excellent performance. I also upgraded us to Ubuntu 10.04 and Postgres 8.4. The result was a resounding success! Memory usage and CPU load on each of the web nodes dropped dramatically. Swap usage dropped to almost nothing. The overall responsiveness of the site improved noticeably, and the timeout errors and OGR failures disappeared entirely. If you'd like to give this stack a try, read on for an overview of the setup on Ubuntu 10.04. I'm using the standard Ubuntu source package for Nginx, but modifying it slightly and them installing it with … -
Django 1.2.3 lançado
Django 1.2.3 lançado -
Django 1.2.3 lançado
Django 1.2.3 lançado -
Entorns virtuals
Quan un es dedica a la programació seriosa amb Python (ja sigui amb Django o amb qualsevol altre framework) hi ha un parell de coses que s'han de tenir en compte: saber amb quina versió de Python programarem i si aquesta versió estarà suportada per la distribució del servidor de producció és una d'elles, potser la més simple. Una altra un poc més complexa és la de plantejar-nos des del principi com durem el mantenimient de l'aplicació. Amb els servidors dedicats cada cop a més bon preu, no és genys extrany plantejar-se tenir un servidor dedicat per les nostres aplicacions web en Python per exemple. És també molt habitual que les aplicacions tenguin un cicle de vida molt més llarg que les llibreries que hem utilitzat per a crear-les. Ara podem fer servir la versió 1.2.3 de Django, però d'aquí tres o quatre mesos tindrem la 1.3, amb altres llibreries pot passar una cosa semblant. Quan tenim una aplicació en producció la màxima sempre ha de ser la de si no està trencat no ho arreglis. Si la nostra aplicació funciona amb Django 1.1 i hem anat aplicant els pegats de seguretat, llavors plantejar-nos migrar a una versió major és … -
New mercurial mirror for Django stable branch 1.2
I have tried for the last few years to use one of the mercurial mirrors on bitbucket.org to follow Django. Since far before Django 1.0 was released, I was following trunk, but I have switched to the stable branch around Django 1.1. I’ve always had problems with the mirrors on bitbucket, they seem mostly unmaintained. [...] -
Python libwkhtmltox module – wrapping a C library using Cython – convert HTML to PDF
First of all, big shout out to antialize for creating wkhtmltopdf (github repo). Also, this project is being hosted on GitHub @ http://github.com/mreiferson/py-wkhtmltox. wkhtmltox What is wkhtmltox you ask? It's a utility built on Nokia's Qt framework for converting HTML (including images, CSS, and Javascript) to a PDF or image. When Qt introduced it's webkit [...] Related posts:Convert HTML to PDF in PHP (libwkhtmltox extension) Python data sharing in the multiprocessing module Django URL Parameter Passing and Python Strings -
OAuthcalypse Now: Tweeting with Twitter, OAuth and Django
The Twitter OAuthcalypse hit me last week. Back in July, I used Twitter’s basic authentication scheme in a new site I’m working on (wantbox.com) to easily send out tweets via my @wantbox account whenever someone posted a new “want” to the site. This integration took about 30 minutes to research and implement. All I had to do was put my twitter username and password in my Django project’s settings.py file, pip install the python-twitter app into my virtualenv and then use: from django.conf import settings import twitter api = twitter.Api(username=settings.TWITTER_USERNAME, password=settings.TWITTER_PASSWORD) api.PostUpdate('Someone in 02481 wants "a home gym" %s' % extra_stuff) The resulting tweet would appear in my @wantbox stream appearing to come “via API”. Easy-peasy. Last week, however, I started getting “401 Unauthorized” errors whenever I tried to post to Twitter. Clearly the Twitter API team had officially turned off basic authentication and was now requiring all apps to connect using OAuth. Yesterday around lunchtime I stopped work on the fun new wantbox feature I was working on so I could “quickly fix” my broken Twitter posting. Oh boy…quickly and OAuth clearly don’t play well together. I tried a bunch of solutions which ultimately failed. I worked through the … -
Безопасные умолчания
По наводке Романа Ворушина почитал пост Дика Липтона о том, что в проектировании систем должны закладываться безопасные умолчания. И мне вспомнилась похожая штука из истории Джанго. Когда-то давно у модели пользователя был метод is_anonymous(), который предполагалось проверять в шаблонах для определения, что показывать незалогиненному пользователю: {% if user.is_anonymous %} Login... {% else %} Hi, {{ user }} {% endif %} А потом Гэри Вилсон справедливо заметил, что это может быть не очень безопасно: если в шаблоне не будет переменной user или человек ошибётся в написании user.is_anonymous, то по умолчанию отработает та часть шаблона, которая показывается залогиненному юзеру. И с тех пор у юзера вместо is_anonymous появился обратный метод -- is_authenticated, условие поменялось на обратное, и теперь в случае ошибок шаблон не вываливает всем подряд залогиновую информацию. -
Безопасные умолчания
По наводке Романа Ворушина почитал пост Дика Липтона о том, что в проектировании систем должны закладываться безопасные умолчания. И мне вспомнилась похожая штука из истории Джанго. Когда-то давно у модели пользователя был метод is_anonymous(), который предполагалось проверять в шаблонах для определения, что показывать незалогиненному пользователю: {% if user.is_anonymous %} Login... {% else %} Hi, {{ user }} {% endif %} А потом Гэри Вилсон справедливо заметил, что это может быть не очень безопасно: если в шаблоне не будет переменной user или человек ошибётся в написании user.is_anonymous, то по умолчанию отработает та часть шаблона, которая показывается залогиненному юзеру. И с тех пор у юзера вместо is_anonymous появился обратный метод — is_authenticated, условие поменялось на обратное, и теперь в случае ошибок шаблон не вываливает всем подряд залогиновую информацию. -
Conheça o Django Packages
O Daniel Greenfeld publicou em seu blog o lançamento do Django Packages (Announcing Django Packages). O objetivo do site é listar todos os pacotes, CMS, plugins e aplicativos para deixar seus projetos em Django ainda mais completo e eficiente. Foi uma ideia sensacional, reunir em um único local tudo (ou quase tudo) que foi desenvolvido pela comunidade Django. O site está organizado em categorias (Apps, Frameworks, Projects, Utilites, etc) e a ordenação dos projetos é feita através de várias métricas, como número de downloads no Pypi, número de commits, número de seguidores, etc. Com isso é possível determinar se uma app tem seu desenvolvimento ativo, quantas pessoas contribuem, etc. Isso ajuda muito na busca e tomada de decisão. Confira o Django Packages em http://djangopackages.com/ O post Conheça o Django Packages apareceu primeiro em Christiano Anderson. -
Django quick tips – using template filters in your views
Django has some very useful template filters, like slugify, which turns a string with spaces into a suitable url slug, and title, which turns any string into title case. Have you ever wanted to use these in your views? All you need to do is add this import: from django.template.defaultfilters import * You can replace [...] -
Django full text search, purely Python
This is a Django full text search module, written purely in Python, using the power of regular expressions, and is fully compatible with Google App Engine server. The search module is given below, along with a code snippet to show how it works with Django or non-rel based GAE projects. The example has been simplified to show how it works with text search on the different 'Post' entries in a 'Blog' application. import re def get_keywords(query_string): """Accepts a search query string and returns a list of search keywords. """ # Regex to split on double-quotes, single-quotes, and continuous # non-whitespace characters. split_pattern = re.compile('("[^"]+"|\'[^\']+\'|\S+)') # Pattern to remove more than one inter white-spaces. remove_inter_spaces_pattern = re.compile('[\s]{2,}') # Return the list of keywords. return [remove_inter_spaces_pattern.sub(' ', t.strip(' "\'')) \ for t in split_pattern.findall(query_string) \ if len(t.strip(' "\'')) > 0] def get_results(objects, query, field_list): """Returns a QuerySet of filtered objects based on the 'query', upon a QuerySet of 'objects', on the fields specified by the list 'field_list'. """ # Create a string representing the actual query condition for filtering. condition = '' for field in field_list: condition = condition + 're.compile(query_pattern).search(obj.%(field)s) or ' % {'field': field} condition = condition[:-4] # Apply the … -
Django full text search, purely Python
This is a Django full text search module, written purely in Python, using the power of regular expressions, and is fully compatible with Google App Engine server. The search module is given below, along with a code snippet to show how it works with Django or non-rel based GAE projects. The example has been simplified to show how it works with text search on the different 'Post' entries in a 'Blog' application. import re def get_keywords(query_string): """Accepts a search query string and returns a list of search keywords. """ # Regex to split on double-quotes, single-quotes, and continuous # non-whitespace characters. split_pattern = re.compile('("[^"]+"|\'[^\']+\'|\S+)') # Pattern to remove more than one inter white-spaces. remove_inter_spaces_pattern = re.compile('[\s]{2,}') # Return the list of keywords. return [remove_inter_spaces_pattern.sub(' ', t.strip(' "\'')) \ for t in split_pattern.findall(query_string) \ if len(t.strip(' "\'')) > 0] def get_results(objects, query, field_list): """Returns a QuerySet of filtered objects based on the 'query', upon a QuerySet of 'objects', on the fields specified by the list 'field_list'. """ # Create a string representing the actual query condition for filtering. condition = '' for field in field_list: condition = condition + 're.compile(query_pattern).search(obj.%(field)s) or ' % {'field': field} condition = condition[:-4] # Apply the … -
Python Decorators for Djangonauts
If you’ve used Django for any amount of time then you’ve probably come across decorators. They’re the things with the @ signs over the top of your view. The first one you’re likely to see is the @login_required decorator, which requires a user to be logged in before the view will run. If they are [...] -
Autocomplete for Foreign Keys in the Django Admin Explained
When the select drop-down for foreign keys in the Django Admin gets big it can become a usability issue. One solution is to create a custom UI for the the model, but stretching the Django Admin to the limit is one of the fun parts of working with Django. Prior Art The top hit on Google is django-autocomplete. This project is the basis of my approach and therefore much thanks goes to the author. There hasn't been an update since early 2009 and I wasn't able to get it working without a lot of changes. The changes evolved into what I consider a better approach. Another interesting project is django-ajax-selects which is very fancy, complicated looking and actively maintained. It allows for very pretty autocompletes. My solution does it without any AJAX so it is a bit easier to use and makes for an easier case study. An AJAX based solution solves another critical problem: the drop down being so large it takes a long time for the admin page to render. Raw id fields also help to solve this problem albeit in a less elegant way. There are a few other projects, some using YUI, some focusing on many … -
Adding GDirections support to GeoDjango Google Maps
I came across the necessity of drawing directions in a google map using GeoDjango API. But gmap.py doesn’t come with GDirections support built-in in Django 1.2.1. So I decided to add it and fill a ticket with a patch This adds a GDirections wrapper, that is controlled in a directions variable in the GoogleMap object. Of course the google-map.js had to be modified. These are my first 2 cents to GeoDjango project, which I consider a complete other framework apart from Django, that shares structure and philosophy. -
Scaffolding template tags for Django forms
We love Django here at Isotoma, and we love using Django’s awesome form classes to generate self-generating, self-validating, [X]HTML forms. However, in practically every new Django project I find myself doing the same thing over and over again (and I know others do too): breaking the display of a Django form instance up into individual fields, with appropriate mark-up wrappers. Effectively I keep recreating the output of BaseForm.as_p/as_ul/as_table with template tags and mark-up. For example, outputting a login form, rather than doing: {{ form.as_p }} We would do: <p> {% if form.username.errors %} {% for error in form.username.errors %} {{ error }} {% endfor %} {% endif %} {{ form.username.label }} {{ form.username }} </p> <p> {% if form.password.errors %} {% for error in form.password.errors %} {{ error }} {% endfor %} {% endif %} {{ form.password.label }} {{ form.password }} </p> Why would you want to do this? There are several reasons, but generally it’s to apply custom mark-up to a particular element (notice I said mark-up, not styling, that can be done with the generated field IDs), as well as completely customising the output of the form (using <div>‘s instead etc.), and also because some designers tend to … -
Get SQL features on NoSQL with django-dbindexer
With the just released django-dbindexer you can use all Django lookup types ("iexact", "month", "day", etc.) on non-relational DBs like App Engine and MongoDB, even if they're not natively supported by that DB! Also, django-dbindexer can help you with optimizing your code. For instance, case-insensitive filters on MongoDB can't use indexes, so they're not very efficient. With django-dbindexer they can be handled as efficient case-sensitive filters which utilize an index. Sounds too good to be true? Keep reading. Non-relational databases have rather limited query APIs. For example, on App Engine you can't do a case-insensitive "iexact" match. Developers on these platforms have to use ugly workarounds to implement unsupported filters. Poor guys. ;) This is how you'd emulate "iexact" and "month" on App Engine (using djangoappengine): # models.py: class MyModel(models.Model): name = models.CharField(max_length=64) lowercase_name = models.CharField(max_length=64, editable=False) last_modified = models.DateTimeField(auto_now=True) month_last_modified = models.IntegerField(editable=False) def save(self, *args, **kwargs): self.lowercase_name = self.name.lower() self.month_last_modified = self.last_modified.month super(MyModel, self).save(*args, **kwargs) def run_query(name, month): MyModel.objects.filter(lowercase_name=name.lower(), month_last_modified=month) This has several problems: You have to remember to use lowercase_name and lower() and month_last_modified You can't reuse existing Django code without analyzing and modifying all models and queries You can't easily utilize this workaround in the admin interface … -
I Am Discontinuing Telvee
Telvee was originally a Facebook app. It was Burak Büyükdemir‘s idea to create a virtual coffee reading app. Rakı Sofrası was super popular then. We have quickly built and deployed and getting some good results. But the competition wasn’t fair. When I decided to give this software a fair chance to succeed on its very [...] -
Person X is...
Many years ago when I was at ActiveState we had a new manager, I got one of those every month or so it wasn't a big deal. One of the things he said was - he would never use the excuse that a decision will be made because person X said so and they know best. It was 9 years ago, so I can't remember the exact wording. What he was saying is that all decisions can be questioned, things need to be explained and we shouldn't be just blindly following some people. He was also saying that this is bit of elitism, putting other people down. This came back to me a few times as a manager when I made decisions and was questioned. But it really hit me home in slightly different circumstances on the Django mailing lists - and I will point out, this is a rare exception. I've seen at a couple of times people say something like: "our code was written by X, so i doubt there's a bug there", "this was designed by X who has quite a reputation...". Each time, it's felt a bit like the "person X knows best" card has been … -
Django Admin: Making fields read-only for editing
Sometimes, when you are developing a Django website, you want to use the Django admin interface to create and edit your custom, homemade models. How to do this, is well documented on this page on the Django website. However, sometimes you want the edit page to differ from the create page. For example, you might want users to be able to fill in a slug field for a model, but because you are afraid of broken links, you don't want them to be able to edit that slug.Of course you can override the model's save method to raise an exception when somebody tries to edit the slug, but that is both ugly and confusing for the user. What you actually want is a standard text field when you create an object, but a read-only field if you edit an object. From the previously mentioned page, we know that Django supports something called 'readonly_fields' and that the ModelAdmin model has a method called 'get_readonly_fields'. How can we use this information to make a field read-only in edit mode? Simply override the get_readonly_fields method.A silly example:Let's say we have a model called Message, for which we create an admin model called MessageAdmin, … -
Django Simple Captcha et tout devient si simple
Comme d'habitude le mois d'aout fut une vraie folie. Et qui dit mois de folie dit, billet qui prennent du retard. Heureusement que j'ai pu tricher en publiant la première interview. (ben oui c'est beaucoup plus rapide de poser des questions que d'y répondre, enfin beaucoup plus rapide d'écrire les questions dans un mails ...
