Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django patterns, part 2: efficient reverse lookups
One of the main sources of unnecessary database queries in Django applications is reverse relations. By default, Django doesn't do anything to follow relations across models. This means that unless you're careful, any relationship can lead to extra hits on the database. For instance, assuming MyModel has a ForeignKey to MyRelatedModel, this: myobj = MyModel.objects.get(pk=1) print myobj.myrelatedmodel.name hits the database two separate times - once to get the MyModel object, and once to get the related MyRelatedModel object. Luckily, it's easy to get Django to optimise this into a single call: myobj = MyModel.objects.select_related.get(pk=1) This way Django does a JOIN in the database call, and caches the related object in a hidden attribute of myobj. Printing myobj.__dict__ will show this: {'_myrelatedmodel_cache': [MyRelatedModel: obj], 'name': 'My name'} Now, whenever you call myobj.myrelatedmodel, Django automatically uses the version in _myrelatedmodel_cache rather than going back to the database to get it. Note that this is exactly the same as what happens once the the related object was accessed in the first snippet above - Django caches it in the same way for future use. All select_related() does is pre-cache it before the first access. None of this is new - it's quite well … -
Looking at registration patterns in Django
Django uses several types of registration patterns for some of its most notable features. This entry looks at the way django implements its different types of registries. -
Looking at registration patterns in Django
Most developers who have written a Django application are familiar with the admin interface. In this post I'll talk about the way the admin module uses a registration pattern to allow tools like admin.autodiscover() and admin.site.urls to do their magic. Registration patterns are useful when developing flexible and extensible libraries. By specifying an interface and allowing you to register your custom implementations, the library code remains decoupled from your own custom code. To get an idea of how these patterns work, let's take a look at the django.contrib.admin.sites module, we find a class called AdminSite which is instantiated at the bottom of the file (essentially a singleton that is used by default across your apps). The first lines of the __init__ method reveal that at the heart of this class, there's an attribute called _registry, which is a dictionary of Model classes and ModelAdmin instances. def __init__(self, name=None, app_name='admin'): self._registry = {} # model_class class -> admin_class instance When we import admin and run admin.site.register(), the register method on AdminSite is called, which performs some validation and then adds the model/modeladmin to its internal dictionary: # Instantiate the admin class to save in the registry self._registry[model] = admin_class(model, self) When … -
Looking at registration patterns in Django
Most developers who have written a Django application are familiar with the admin interface. In this post I'll talk about the way the admin module uses a registration pattern to allow tools like admin.autodiscover() and admin.site.urls to do their magic. Registration patterns are useful when developing flexible and extensible libraries. By specifying an interface and allowing you to register your custom implementations, the library code remains decoupled from your own custom code. To get an idea of how these patterns work, let's take a look at the django.contrib.admin.sites module, we find a class called AdminSite which is instantiated at the bottom of the file (essentially a singleton that is used by default across your apps). The first lines of the __init__ method reveal that at the heart of this class, there's an attribute called _registry, which is a dictionary of Model classes and ModelAdmin instances. def __init__(self, name=None, app_name='admin'): self._registry = {} # model_class class -> admin_class instance When we import admin and run admin.site.register(), the register method on AdminSite is called, which performs some validation and then adds the model/modeladmin to its internal dictionary: # Instantiate the admin class to save in the registry self._registry[model] = admin_class(model, self) When … -
Looking at registration patterns in Django
Most developers who have written a Django application are familiar with the admin interface. In this post I'll talk about the way the admin module uses a registration pattern to allow tools like admin.autodiscover() and admin.site.urls to do their magic. Registration patterns are useful when developing flexible and extensible libraries. By specifying an interface and allowing you to register your custom implementations, the library code remains decoupled from your own custom code. To get an idea of how these patterns work, let's take a look at the django.contrib.admin.sites module, we find a class called AdminSite which is instantiated at the bottom of the file (essentially a singleton that is used by default across your apps). The first lines of the __init__ method reveal that at the heart of this class, there's an attribute called _registry, which is a dictionary of Model classes and ModelAdmin instances. def __init__(self, name=None, app_name='admin'): self._registry = {} # model_class class -> admin_class instance When we import admin and run admin.site.register(), the register method on AdminSite is called, which performs some validation and then adds the model/modeladmin to its internal dictionary: # Instantiate the admin class to save in the registry self._registry[model] = admin_class(model, self) When … -
Looking at registration patterns in Django
Most developers who have written a Django application are familiar with the admin interface. In this post I'll talk about the way the admin module uses a registration pattern to allow tools like admin.autodiscover() and admin.site.urls to do their magic. Registration patterns are useful when developing flexible and extensible libraries. By specifying an interface and allowing you to register your custom implementations, the library code remains decoupled from your own custom code. To get an idea of how these patterns work, let's take a look at the django.contrib.admin.sites module, we find a class called AdminSite which is instantiated at the bottom of the file (essentially a singleton that is used by default across your apps). The first lines of the __init__ method reveal that at the heart of this class, there's an attribute called _registry, which is a dictionary of Model classes and ModelAdmin instances. def __init__(self, name=None, app_name='admin'): self._registry = {} # model_class class -> admin_class instance When we import admin and run admin.site.register(), the register method on AdminSite is called, which performs some validation and then adds the model/modeladmin to its internal dictionary: # Instantiate the admin class to save in the registry self._registry[model] = admin_class(model, self) When … -
Create Your Own Local Copy of the Django Documentation
sudo easy_install Sphinx Inside your local SVN checkout of Django: cd docs make html Now you’ll have a beautiful local copy of the documentation to browse for those rare moments when you’re away from the internet (perhaps you’re in a fort?). Just point your browser to: file:///path/to/your/django/docs/_build/html/index.html Source eddymulyono -
Simple integration with GitHub - django-github
django-github is a Django app for integration with GitHub. -
How we create and deploy sites fast with virtualenv and Django
A commenter on my last post was curious how we use virtualenv to deploy sites and how it is helpful. It goes a bit deeper than that. There are a few parts that make everything work. Pieces of the puzzle Philosophy of modular, pluggable applications with well-defined dependencies. Ideally I would love for someone to be able to check off the applications that they need in a project and everything is ready. We’re not there yet, but it is a great goal. Easy source repository creation and access management. We started on Subversion, and creating a new repository for a new modular app was a bit of a pain. If there is pain, it is avoided, so the repository wouldn’t get created. ProjectMgr (and then django-repositories) evolved out of that problem. Easy creation, sharing and access management from the Django admin. Automated project and application setup. This piece fit into place with something called Django Project Skeleton I saw from Eric Florenzano and for the life of me, I can’t remember where and can’t locate it now. Somewhere he published some code for creating a project with virtualenv with a simple command. So major props to Eric for the very cool idea and code. We … -
The power of Q
Q objects are a great tool in Django -
Benefits of moving to Django
Join the revolution – new possibilities are opened up by the switch to Django. -
Benefits of moving to Django
Join the revolution – new possibilities are opened up by the switch to Django. -
Benefits of moving to Django
Join the revolution – new possibilities are opened up by the switch to Django. -
.NET magazine features expert article by Mercurytide
The article focuses on our experiences of moving to Django from an older framework and how it affected our business. -
.NET magazine features expert article by Mercurytide
The article focuses on our experiences of moving to Django from an older framework and how it affected our business. -
.NET magazine features expert article by Mercurytide
The article focuses on our experiences of moving to Django from an older framework and how it affected our business. -
Creant Bits, el déjà vu
Em complau anunciar una segona edició de Creant Bits destinada a tots aquells i aquelles que no poguéreu assistir a la primera. Els contingut seran bàsicament els mateixos, en tot cas mirarem de resoldre algunes mancances de la primera presentació, però en un 99% serà tot el mateix: Introducció bàsica al llenguatge Python, amb exercicis. Introducció a Django: arquitectura i possibilitats Instal·lació d'una aplicació Django a Apache. La sala serà la mateixa que a la presentació anterior. Creant Bits, el déjà vu 29 de gener de les 16:00 a les 21:00 Sala de Formació - Parc Bit Pensau a dur el portàtil carregat amb el Python instal·lat. Hi ha connexió inhalàmbrica a la sala i el Parc Bit ens deixa un projector. La sala té una capacitat per a 20 persones màxim. Per apuntar-vos deixau un comentari a aquest apunt. Per cert, aquesta vegada tampoc hi ha catering! :) 23 comentaris, 0 trackbacks (URL) Automatic translations of this post by Apertium -
django-forum
twitter ready version: We have released a Django forum application, with some cool features not in any other Django based forum. You can get it here or see it in action. blog version There are quite a few Django based forum applications, so why another? Its a bit of a rhetorical question, as the answer [...] No related posts. -
Dynamic Translation Apps for Django
When I needed multi-language flatpages and flatblocks for telvee I searched for available Django apps that do dynamic translation. By dynamic translation, I mean translations are entered and stored in the database. As I said I needed to be able to translate both full pages and chunks of text that I can include into another [...] -
What a difference a year makes
The end of the year makes me reminisce about all that happened in the past 12 months. Web development at The Washington Times has changed dramatically, both in technology and process. Here are just a few things that have changed: From To Django 0.91 Django 1.1 mod_python mod_wsgi No virtualenv usage using virtualenv One site 8+ internal/external sites 5-6 content servers 1 content server + Varnish (and a backup for each and without hardware upgrades) Just servers Heavy usage of virtual machines Painful and manual deployment process Quick deployment process with Fabric Tightly integrated apps and a monolithic site More modular site with apps in separate repositories One private svn repository 50+ public and private svn and git repositories Five team members Six team members PostgreSQL 8.1 PostgreSQL 8.3 Subversion Git Python 2.3 Python 2.6 There were also some new improvements: Created a new framework for starting and deploying sites and creating apps Dramatically improved the monitoring of our infrastructure Released 30 apps under an open source license Began mirroring our public repositories on Git Hub Created a web site for our department with a blog and showing our open sourced projects Increased our focus on tests and documentation Converted an external PHP website to internal Django site, … -
Django 1.2 alpha 1 lançado
Django 1.2 alpha 1 lançado -
Django 1.2 alpha 1 lançado
Django 1.2 alpha 1 lançado -
Send someone from a charity to DjangoSki
Thanks to sponsorship from the Python Software Foundation we've got some free tickets to give away to people from charities or non-profits. Do you know someone who uses Django in a charity? Or are you at a charity? Do you use Django or want to learn about it? Like skiing, snowboarding or just hanging out in Whistler? Then nominate someone, or yourself. We've got a limited number of tickets and time is short - so hop to it. Fill out the form here. Note: the image isn't relevant, but was one of the first hits on Flickr for ticket. It's much colder in Whistler. Update: people chosen and contacted. -
Sechstes Treffen der Django-UserGroup Hamburg
Das sechste Treffen der Django-UserGroup Hamburg findet am Dienstag, den 12.01.2010 um 19:30 statt. Wie bei den letzten Malen treffen wir uns wieder in den Räumen der CoreMedia AG in der Ludwig-Erhard-Straße 18 in 20459 Hamburg. Eine Anfahrtsbeschreibung gibt es via Google Maps. Bitte am Eingang Ludwig-Erhard-Straße 18 bei CoreMedia AG klingeln, in den 3. Stock fahren und oben am Empfang nach der Django-UserGroup fragen. Da wir in den Räumlichkeiten einen Beamer zur Verfügung haben hat jeder Teilnehmer die Möglichkeit einen kurzen Vortrag (Format: Lightning Talks oder etwas länger) zu halten. Ich werde diesmal ein bisschen über den neu gegründeten Deutschen Django-Verein erzählen und bei Interesse einen Überblick über die Änderungen im Django-Trunk der letzten Tage/Wochen geben, da sich in Vorbereitung auf das 1.2 Release bereits einige Interessante Änderungen ergeben haben. Weitere Vorträge von anderen Teilnehmern ergeben sich erfahrungsgemäß vor Ort. Eingeladen ist wie immer jeder der Interesse hat sich mit anderen Djangonauten auszutauschen. Eine Anmeldung ist nicht erforderlich. Weitere Informationen über die UserGroup gibt es in unserem Git Repository unter www.dughh.de und im Wiki des Deutschen Django-Vereins. -
Getting Django + MySQL running again on Snow Leopard
Previously… Install the latest Xcode Tools from your Snow Leopard installation DVD Re symlink things to /Library/Python/2.6/site-packages (Leopard used 2.5) Django Any other thing you had symlink’d in 2.5 MySQL + Python Install MySQL from source like Dan says but use the latest version of MySQL (5.1.42 in my case) instead of the version he [...]