Django community: RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
Django Project Setup Conveniences
Whenever I start a new Django project, there are several common steps that I to help standardize my setups. In settings.py...I define a PROJECT_ROOT variable which contains the path to the project directory. This is useful for various settings in the setup.py:import sys, osPROJECT_ROOT = os.path.dirname(__file__)I set my MEDIA_ROOT to be a path relative to the PROJECT_ROOT. Of course, I will need to create this directory on the filesystem. MEDIA_ROOT = os.path.join(PROJECT_ROOT, '..','htdocs','media').replace('\\','/') + '/'And I set a relative TEMPLATE_DIRS path. I will need to make this directory as well.TEMPLATE_DIRS = ( os.path.join(os.path.dirname(__file__), 'templates').replace('\\','/'),)Sometimes I add extra directories to the path so I can store specific packages within the project directory. (I might use this if I want to keep all related modules together).sys.path.insert(0, os.path.join(PROJECT_DIR, "contrib"))sys.path.insert(0, os.path.join(PROJECT_DIR, "src"))I generally like to put admin media in the following location: ADMIN_MEDIA_PREFIX = '/media/admin/'Almost all the time, I install the following modules in INSTALLED_APPS:'south', # django-south'django_extensions', # django-command-extensionsIn urls.py...If I want to use the Django debug server, I'll set this near the top:from django.conf import settingsurlpatterns = patterns('',)if settings.DEBUG: urlpatterns = patterns('', (r'^media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': settings.MEDIA_ROOT}), ) -
Introduction
This blog will document my adventures in Django, the Python web framework. It is a direct fork of my Linux Info blog, but will be specifically utilized for documenting my Django activity. Though my aim is to post Django code and examples that are helpful, there will most certainly be better/different ways to approach various challenges. Any comments are much appreciated.Joe -
Django-nonrel – NoSQL support for Django | All Buttons Pressed
Django-nonrel – NoSQL support for Django. Liefert einen ersten Ansatz in Django verschiedene NoSQL Datenbanken zu integrieren, und zwar auf Ebene des Django-ORM. Backends für MongoDB (nein Danke), AppEngine und Cassandra sind in der Mache. Besonders Cassandra interessiert mich im Moment. -
Slides from my presentation at the Web Performance Meetup
-
Growl type notifications in Django
First, a little background Django has an excellent messages framework which provides support for cookie and session-based messaging, for both anonymous and authenticated users. The messages framework allows you to temporarily store messages in one request, and retrieve them for display in a subsequent request (usually the next one). Every message is tagged with a specific level determining its priority (e.g. success, info, error). For example, in a view you can send a message: from django.contrib import messages messages.success(request, "Profile details updated.") Then in the template you can display it, for example: {% for message in messages %} <li class="{{ message.tags }}">{{ message }}</li> {% endfor %} The Django admin interface displays messages in bar type fashion. I liked this implementation and copied it for the TurnKey Hub, with the added visual tweak of fading out the message bar after timeout (or when clicked). It's simple, minimal, and has worked well until now. But our needs are changing as the Hub is evolving. We need more flexibility and power. Our current implementation falls short in the following: Messages can't be specified as sticky (so they don't auto-close). Can't be programmatically created and closed for use via AJAX. Moves the whole page down, then up again (a little annoying). Limited … -
Growl type notifications in Django
First, a little background Django has an excellent messages framework which provides support for cookie and session-based messaging, for both anonymous and authenticated users. The messages framework allows you to temporarily store messages in one request, and retrieve them for display in a subsequent request (usually the next one). Every message is tagged with a specific level determining its priority (e.g. success, info, error). For example, in a view you can send a message: from django.contrib import messages messages.success(request, "Profile details updated.") Then in the template you can display it, for example: {% for message in messages %} <li class="{{ message.tags }}">{{ message }}</li> {% endfor %} The Django admin interface displays messages in bar type fashion. I liked this implementation and copied it for the TurnKey Hub, with the added visual tweak of fading out the message bar after timeout (or when clicked). It's simple, minimal, and has worked well until now. But our needs are changing as the Hub is evolving. We need more flexibility and power. Our current implementation falls short in the following: Messages can't be specified as sticky (so they don't auto-close). Can't be programmatically created and closed for use via AJAX. Moves the whole page down, then up again (a little annoying). Limited … -
Growl type notifications in Django
First, a little background Django has an excellent messages framework which provides support for cookie and session-based messaging, for both anonymous and authenticated users. The messages framework allows you to temporarily store messages in one request, and retrieve them for display in a subsequent request (usually the next one). Every message is tagged with a specific level determining its priority (e.g. success, info, error). For example, in a view you can send a message: from django.contrib import messages messages.success(request, "Profile details updated.") Then in the template you can display it, for example: {% for message in messages %} <li class="{{ message.tags }}">{{ message }}</li> {% endfor %} The Django admin interface displays messages in bar type fashion. I liked this implementation and copied it for the TurnKey Hub, with the added visual tweak of fading out the message bar after timeout (or when clicked). It's simple, minimal, and has worked well until now. But our needs are changing as the Hub is evolving. We need more flexibility and power. Our current implementation falls short in the following: Messages can't be specified as sticky (so they don't auto-close). Can't be programmatically created and closed for use via AJAX. Moves the whole page down, then up again (a little annoying). Limited … -
Merar – The Emerging Markets Investment Network v2.0 …
… or how we redesigned Merar`s website If you follow me on Twitter maybe you have noticed that a week ago(to be more precise 11th of March) I tweeted about the new version of Merar. Unfortunately it took me 9 days before I find some time to post about what we do and what we [...] -
Fer servir un ORM o no
Arrel del darrer post s'ha establert un nou fil relacionat amb la conveniència o no de fer servir un ORM en les nostres aplicacions quan l'sql directe pot ser més eficient. En Jan Carreres, el "responsable" d'aquest article fa una sèrie d'apreciacions que crec que donen per un nou post, més que res per poder mantenir la discusió en baix el seu propi concepte. Així doncs acomodeu-vos al seient, que començam ... Però què dimonis és un ORM ORM són les sigles de Object Relational Mapping, és a dir, s'anomena ORM a aquella llibreria o procés que fa la conversió d'estructures de dades relacionals cap a estructures de dades orientades a objectes. És a dir, passam de fer feina amb taules i files a fer feina amb classes i instàncies d'aquestes classes. Passam de fer feina de camps a fer feina amb propietats dels objectes. No hi ha una única aproximació als ORM. Christian Bauer i Gavin King al llibre Hibernate in Action, anomenen quatre característiques comuns a tot ORM: Una API per executar operacions CRUD (Create, Retrieve, Update, Delete) en els objectes. Un llenguatge o una API per especificar les consultes que fan referència a les classes i a … -
Stale formsets and the back button
I have a problem on one of my projects: I have a page with a form that depends on what is stored in the database. If your using django formsets or have some form that saves over multiple objects you have this problem too. The user saves the form, data gets saved. However, if the user uses the back button he will get a page with the old form (that expects different data in the database). If the form gets resubmitted all kinds of problems may appear. I had one case when you could get a ValueError: invalid literal for int() with base 10: '' if you resubmit a formset but instead of a existing object you have a new one. Easy to pull off by a regular user if he has multiple tabs opened. The best solution, I think, is to reload the page when the users goes back in history. Turns out this is easy to pull off with some http headers: Cache-Control: no-cache, must-revalidate, no-store Pragma: no-cache The “no-store” option actually makes browses re-request when using the back button. Also, I’ve seen people adding “post-check=0, pre-check=0″ to Cache-Control. Do NOT use those. They are Microsoft extensions to … -
Stale formsets and the back button
I have a problem on one of my projects: I have a page with a form that depends on what is stored in the database. If your using django formsets or have some form that saves over multiple objects you have this problem too. The user saves the form, data gets saved. However, if the user uses the back button he will get a page with the old form (that expects different data in the database). If the form gets resubmitted all kinds of problems may appear. I had one case when you could get a ValueError: invalid literal for int() with base 10: '' if you resubmit a formset but instead of a existing object you have a new one. Easy to pull off by a regular user if he has multiple tabs opened. The best solution, I think, is to reload the page when the users goes back in history. Turns out this is easy to pull off with some http headers: Cache-Control: no-cache, must-revalidate, no-store Pragma: no-cache The "no-store" option actually makes browses re-request when using the back button. Also, I've seen people adding "post-check=0, pre-check=0" to Cache-Control. Do NOT use those. They are Microsoft extensions to … -
Stale formsets and the back button
I have a problem on one of my projects: I have a page with a form that depends on what is stored in the database. If your using django formsets or have some form that saves over multiple objects you have this problem too. The user saves the form, data gets saved. However, if the user uses the back button he will get a page with the old form (that expects different data in the database). If the form gets resubmitted all kinds of problems may appear. I had one case when you could get a ValueError: invalid literal for int() with base 10: '' if you resubmit a formset but instead of a existing object you have a new one. Easy to pull off by a regular user if he has multiple tabs opened. The best solution, I think, is to reload the page when the users goes back in history. Turns out this is easy to pull off with some http headers: Cache-Control: no-cache, must-revalidate, no-store Pragma: no-cache The "no-store" option actually makes browses re-request when using the back button. Also, I've seen people adding "post-check=0, pre-check=0" to Cache-Control. Do NOT use those. They are Microsoft extensions to … -
It's alive
Houston, we have liftoff We are pleased to announce that DjangoCon Europe 2011 is open for business. Tickets sales are underway, hotel reservations can be booked, and talk submissions are being accepted. Deadlines Unfortunately, this year we got off to a very late start with registration—our sincere apologies. As a result, there are several deadlines already approaching. Notably, the conference hotels will only honor the special room rates if booked before Friday, April 1st. This is something we cannot control, and so we urge you to book your hotels in time to take advantage of the discounted rates. Discounted hotel rooms available until: Friday, April 1st. Early bird registration is available until: Friday, April 1st. Regular rate is available until: Friday, May 13th. Talk submission deadline is: Friday, April 15th. Acceptance announcements are on: Sunday, May 1st. Talks This edition of DjangoCon will focus on advanced topics. If you have anything in-depth and interesting to present to your fellow Djangonauts, please submit a talk. Sponsors Additional sponsors for this year’s DjangoCon would be most welcome. If you (or someone you know) might be interested in supporting this prominent event in every djangonaut’s calendar, please have a look at the sponsor … -
Deploying Django projects
In the wake of `recent discussions `_ about deployment, I feel the need to tell you how easy my deployment has gotten using the old style tools like `nginx `_, `uwsgi `_, and `supervisord `_ on a dedicated (or VPS) server. Read on to find out how it stands the chance against the new online services such as `ep.io `_ or `DjangoZoom `_. -
Using Signals to Create User Profiles in Django 1.3
Django’s built-in User model is rather thin—deliberately so, since it’s designed to service a broad range of projects. If you burden your User model with additional fields and methods, you risk breaking compatibility with other Django apps or with future … Continue reading → -
Sprinting on Django: A Layperson's Perspective
We just got back from another fun and successful PyCon. While we didn't get to stay for much of the sprints we did get to spend some time in the Django sprint Sunday and Monday. Monday morning I was there early and I noticed a bit of confusion among the Django sprinters. While I'm not ... -
I become a PhD Student
I am happy to say that I successfully passed the entry tests for a PhD student. So now I am part of SULSIT(State University of Library Studies and Information Technologies) PhD program. The program`s name is “Automated Systems for Information processing and information management” and my thesis will be “Research of the current methods and [...] -
Using Dojo Rich Editor with Django's Admin
Many years ago I decided to replace plain text areas in Django's Admin with rich text editor, so I can edit HTML on my blog using WYSIWYG. Six (yes, 6) years ago I looked around and selected TinyMCE. Over time it turned out that I was forced to upgrade TinyMCE and the link script I had because new browsers continue breaking my rich editor editing. Finally it stopped working again in all modern browsers, and I decided that enough is enough. It is time to replace it. This time I settled on Dojo's Rich Editor hosted on Google CDN — simple, functional, less work to set up. Selecting features Adding Dojo's editor to Django's Admin was very simple. The most complex part turned out to be selecting what cool features I want to use. See, dijit.Editor is fully pluggable, and it is easy to extend with your own plugins. Some day I'll do just that, but for now let's use what's available. dijit.Editor comes with two sets of plugins. Let's go over them and select plugins we want to use. The first set is in Dijit's editor plugin repository: FullScreen: allows editor to take over the whole page. Toggleable. This … -
Using Dojo Rich Editor with Django's Admin
Many years ago I decided to replace plain text areas in Django’s Admin with rich text editor, so I can edit HTML on my blog using WYSIWYG. Six (yes, 6) years ago I looked around and selected TinyMCE. Over time it turned out that I was forced to upgrade TinyMCE and the link script I had because new browsers continue breaking my rich editor editing. Finally it stopped working again in all modern browsers, and I decided that enough is enough. It is time to replace it. This time I settled on Dojo’s Rich Editor hosted on Google CDN — simple, functional, less work to set up. Selecting features Adding Dojo’s editor to Django’s Admin was very simple. The most complex part turned out to be selecting what cool features I want to use. See, dijit.Editor is fully pluggable, and it is easy to extend with your own plugins. Some day I’ll do just that, but for now let’s use what’s available. dijit.Editor comes with two sets of plugins. Let’s go over them and select plugins we want to use. The first set is in Dijit’s editor plugin repository: FullScreen: allows editor to take over the whole page. Toggleable. This … -
New Job Posting: Linux Systems Administrator with Python/Django experience
I'm delighted to announce that we've just published another job posting for a Linux Systems Administrator at Caktus.  The position will involve maintaining existing Linux servers, designing and building highly-scalable deployments, and assistance with Django deployment and development as time permits.  This is a full-time position, with benefits, and is based out of our Carrboro, ... -
Solapament d'intervals ara amb Django
Segueixo amb la vena friki, ahir damunt el solapament d'intervals de mode genèric i avui veurem la implementació d'aquesta idea a un model Django. class Oferta(models.Model): """Una oferta que va per rang""" nom = models.CharField(max_length=200) inici = models.DateField() fi = models.DateField() activa = models.BooleanField(default=True) class Meta: verbose_name="Oferta" verbose_name_plural="Ofertes" def __unicode__(self): return self.nom El model com veis és molt senzill, una oferta pot estar activa o no i pertany sempre a un rang de dates. Queda fora de l'exemple la determinació de si admetem solapament de dates per una oferta, que es fareia de manera semblant al la cerca que ara farem. La idea és que hem d'aconseguir que amb l'ORM de Django nodelar una consulta del tipus not ((x1<y0) or (y1<x0)). Els filtres per defecte el que fan es un and, per la qual cosa no ens serveixen directament. El que farem és utilitzar una característica de l'ORM anomenada funció Q que ens permete afegir condicons de filtratge múltiples i fer que vaign per OR enlloc de per AND. from django.db.models import Q Ara sols queda fer la consulta. Particularment si són consultes que poden ser susceptibles de fer-se servir a varis llocs o que estan molt relacionades amb el … -
Using disqus comments and django-localeurl
Lately I have added comments to my company blog. We have it localized, so things turned out to be not so straight forward as one can think. django-localeurl This neat piece of code allows us to localize our URLs. You can find it in its bitbucket repository. So, in my blog I have four languages (english, catalan, spanish and french), each one with a different prefixed URL: http://example.com/blog/post_slug/ http://example.com/ca/blog/post_slug/ http://example.com/es/blog/post_slug/ http://example.com/fr/blog/post_slug/ Note that the english version doesn't have any prefix actually; this is a default from django-localeurl but you can change it if you want. disqus url So we want to include, of course, comments to our blog, and we are going to use disqus, a well-known service that makes our life more enjoyable without having to carry the burden of spam comments, implementing all the ubiquitous facebook, twitter, and many more logging services, to name a few. When using the universal JavaScript embed code, by default this script uses window.location to send the URL of the current page. As long as we are using localized URLs, if we don't modify this behavior then each localized URL would have its own comments. Hopefully, we can specify our URL with the … -
Django Cloud Browser
Ryan’s released a new version of his Cloud Browser application to PyPi. It supports S3 and Rackspace Cloud Files. Read his blog for the details. Tagged: Django -
Caktus Consulting Group Sponsors PyCon 2011
PyCon 2011 Atlanta is just around the corner, and I'm proud to announce that Caktus is a gold sponsor at the conference this year! We sponsored DjangoCon in both 2009 and 2010, and this year agreed to extend that support to the Python community in general.PyCon US is the annual gathering of software developers who ... -
Using Jinja2 To Generate LaTeX
I've generated PDF documents from webapps using XSL-FO with Apache FOP, HTML with XHTML2PDF, Python with ReportLab, SVG with Inkscape. But I still obtain the best results – in terms of robustness and typographic beauty – with LaTeX. However, writing LaTeX templates in Django's template language is hindered by syntax conflicts: both languages use '{}' and '%'. Since Django does not allow changes to its template syntax, I decided to use Jinja2 for a new project. After toying with several obscure escape sequences, I settled on a rather straightforward approach: latex_jinja_env = jinja2.Environment( block_start_string = '\BLOCK{', block_end_string = '}', variable_start_string = '\VAR{', variable_end_string = '}', comment_start_string = '\#{', comment_end_string = '}', line_statement_prefix = '%-', line_comment_prefix = '%#', trim_blocks = True, autoescape = False, ) … which plays nice with syntax highlighting: %- if graphicspath \graphicspath{{\VAR{graphicspath}}} %- endif \section{\VAR{obj.name|title}} \BLOCK{for item in items} \paragraph{\VAR{item.name|title}} \VAR{item.description} \BLOCK{endfor} \enjoy{!}
