Django community: Community blog posts RSS
This page, updated regularly, aggregates Community blog posts from the Django community.
-
A PHP developer looks into Django
Thierry Schellenbach has published a very interesting article about his study for selecting a Web framework. A PHP developer that values the Symfony framework, after weighing the issue along with a colleague he decided that for many projects Django and Python are a better fit than Symfony and PHP. This is not a typical holy [...] -
AGPLv3 explained
I think there are lots of people which misunterstand the Affero GPL v3, so I decided to write this entry to clarify some things. Keep in mind I'm not a lawyer, so you should read my advice with a grain of salt. I've been using free software licenses for some years and I always take the time to read and understand them, but that doesn't mean I cannot make mistakes or misunderstand some sections. You can Sell commercial software under an AGPLv3 license: Nobody prevents you from selling AGPLv3 licensed code, even when you didn't write it. However, customers buying the software from you must abide by the license terms. Paying for an AGPLv3 product doesn't mean you can avoid the license terms. However, if you're the copyright owner, you can sell the same software under a different license. Build another software on top of it: AGPLv3 grants you permission to download and modify any software which you can use, even if it's over a network (this an important difference with the GPLv3). You're free to modify it or use it into another project, making your project a derivative work of the original software. Link to or use BSD … -
Building a website API with Django. Part 6: Documentation
This entry puts and end to "Building a website API with Django". I think I've covered everything you need to build a website API with Wapi, so it's now time for you to start playing with it. I hope you've enjoyed reading this series as much as I enjoyed writing it. I've finally pylinted and documented almost all the code, so Wapi 0.2 should be released in the next few hours. From now, I'll try to keep the current API and every backwards incompatible change will be documented. Documenting your API with Wapi Documenting your functions As we've seen on part 4 on this series, every API parameter takes an optional third argument which documents it. In addition, every function docstring is also passed to the documentation template. Furthermore, validators applied to parameters are also autodocumented. Let's see an example: @readonly @required_parameter('type', int, _('Admin division type, ranging from 1 to 4.'), validators=RangeValidator(min_value=1, max_value=4)) @required_parameter('id', int, _('The administrative division id.')) def geo__admin(self, request, dct): """Returns information for the given administrative division type and id. Keep in mind that administrative divisions identificators are not guaranteed to be permanent, as it happens with geoname identifiers.""" If you want to check how it looks … -
Django vs Symfony
As you can see from the posts (one, two) I’ve always been a big Symfony fan. Symfony is really great, but my current favourite is clearly Django. I had to dive deep into python to use it, but it was well worth the effort. Choosing Django: Django has a few killer features which make it a better [...] -
3. Customizing the Simple CMS
This is part 3 of a series of posts on James Bennett's excellent Practical Django Projects. The table of contents and explanation can be found here. Improving the Search Function with Keywords On page 34 when defining your first model class, remove the Admin class to replace it with new a separate newforms admin file (hereafter just admin). If I've ignored code that works just fine I just use -
Aplicação comments do Django refatorada
Boa notícia para os desenvolvedores Django! Ontem foi feita a refatoração da aplicação bult-in comments do Django (changeset 8557). Dentre as mudanças, as que mais gostei são: Aquela idéia de FreeComment foi abandonada: agora existe somente um model Comment; foram adicionados os campos email e URL; e agora é documentado! Detalhes de como atualizar seu código para o novo comments em http://docs.djangoproject.com/en/dev/ref/contrib/comments/upgrade/. Se ainda não gosta desta aplicação, existe uma alternativa com suporte a threads: é o django-threadedcomments. -
New App: Django and AWS
I have started a new app over on github called django-aws. It's pretty bare bones right now but wanted to announce it earlier rather than later as I am hoping to: Get some folks who might be interested to help me out. Get some eyeballs on it for recommendations for how to (or how to not) do certain things. I would appreciate any feedback or help that I might be able to scrounge up! This app will have a strict dependency on boto which is a really cool project provides the de facto way for interacting with Amazon Web Services in the Python language. -
New App: Django and AWS
I have started a new app over on github called django-aws. It's pretty bare bones right now but wanted to announce it earlier rather than later as I am hoping to: Get some folks who might be interested to help me out. Get some eyeballs on it for recommendations for how to (or how to not) do certain things. I would appreciate any feedback or help that I might be able to scrounge up! This app will have a strict dependency on boto which is a really cool project provides the de facto way for interacting with Amazon Web Services in the Python language. -
1. Welcome to Django
This is part 1 of a series of posts on James Bennett's excellent Practical Django Projects. The main post can be found here. This is not a critique of James's book, but rather a collection of notes and code revisions to accompany it, both updating it for Django 1.x and things beginners may want to consider. The headings follow the subheadings in the book. Say Hello to Python If you haven't -
Dynamic upload paths in Django
For a while I’ve been using the CustomImageField as a way to specify an upload path for images. It’s a hack that lets you use ids or slugs from your models in the upload path, e.g.: /path/to/media/photos/1234/flowers.jpg or /path/to/media/photos/scotland-trip/castle.jpg CustomImageField no more Since the FileStorageRefactor was merged in to trunk r8244, it’s no longer necessary to use the custom field. Other recent changes to trunk mean that it doesn’t work any more in its current state, so this is a good time to retire it. Pass a callable in upload_to It is now possible for the upload_to parameter of the FileField or ImageField to be a callable, instead of a string. The callable is passed the current model instance and uploaded file name and must return a path. That sounds ideal. Here’s an example: import os from django.db import models def get_image_path(instance, filename): return os.path.join('photos', str(instance.id), filename) class Photo(models.Model): image = models.ImageField(upload_to=get_image_path) get_image_path is the callable (in this case a function). It simply gets the id from the instance of Photo and uses that in the upload path. Images will be uploaded to paths like: photos/1/kitty.jpg You can use whatever fields are in the instance (slugs, etc), or fields in … -
Django and mod_wsgi: A perfect match!
mod_wsgi is an Apache module for serving WSGI-based Python web applications from the Apache HTTP server. Django, along with almost every other Python web framework today, comes bundled with a backend for acting like a WSGI application. A couple of months ago I decided to try it out in spite of mod_python. Discovering and trying out mod_wsgi really suprised me. It can take a massive beating, and outperforms mod_python in every practical aspect. The setup You will need a short Python "bootstrap" script to create a WSGI-handler for your Django project. Here is an example (call it wsgi_handler.py and place it in the root directory of your Django project - the one with manage.py and settings.py): import sys import os sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..') os.environ['DJANGO_SETTINGS_MODULE'] = 'projectname.settings' import django.core.handlers.wsgi application = django.core.handlers.wsgi.WSGIHandler() Finally set up your Apache virtualhost to use mod_wsgi: <VirtualHost *> ServerName www.projectname.org ServerAlias *projectname.org Alias /admin_media /usr/lib/python2.4/site-packages/django/contrib/admin/media <Location /admin_media> Order allow,deny Allow from all </Location> Alias /media /home/user/projectname/media <Location /media> Order allow,deny Allow from all </Location> WSGIScriptAlias / /home/user/projectname/wsgi_handler.py WSGIDaemonProcess projectname user=user group=user processes=1 threads=10 WSGIProcessGroup projectname </VirtualHost> In the WSGIDaemonProcess line, you can easily manage the amount of system resources (measured in processes and threads) mod_wsgi should … -
Django and mod_wsgi: A perfect match!
mod_wsgi is an Apache module for serving WSGI-based Python web applications from the Apache HTTP server. Django, along with almost every other Python web framework today, comes bundled with a backend for acting like a WSGI application. A couple of months ago I decided to try it out in spite of mod_python. Discovering and trying out mod_wsgi really suprised me. It can take a massive beating, and outperforms mod_python in every practical aspect. The setup You will need a short Python "bootstrap" script to create a WSGI-handler for your Django project. Here is an example (call it wsgi_handler.py and place it in the root directory of your Django project - the one with manage.py and settings.py): import sys import os sys.path.append(os.path.dirname(os.path.abspath(__file__)) + '/..') os.environ['DJANGO_SETTINGS_MODULE'] = 'projectname.settings' import django.core.handlers.wsgi application = django.core.handlers.wsgi.WSGIHandler() Finally set up your Apache virtualhost to use mod_wsgi: <VirtualHost *> ServerName www.projectname.org ServerAlias *projectname.org Alias /admin_media /usr/lib/python2.4/site-packages/django/contrib/admin/media <Location /admin_media> Order allow,deny Allow from all </Location> Alias /media /home/user/projectname/media <Location /media> Order allow,deny Allow from all </Location> WSGIScriptAlias / /home/user/projectname/wsgi_handler.py WSGIDaemonProcess projectname user=user group=user processes=1 threads=10 WSGIProcessGroup projectname </VirtualHost> In the WSGIDaemonProcess line, you can easily manage the amount of system resources (measured in processes and threads) mod_wsgi should … -
Building a website API with Django. Part 5: Serialization
Let me start this entry announcing the first beta releases of wapi-0.2 and django-oauthsp-0.2. Keep in mind this code is released under AGPLv3, as per the reasons detailed in this entry. Note also that the API is subject to change before reaching 0.2, this code should be considered as a preview release. Now let's talk about <serializations />! Principles Wapi serializers, as opposed to the Django serializers, let you fully customize how an object is serialized. You can even specify multiple ways of serializing an object, depending on multiple things. However, this flexibility comes with a price: complexity. Declaring serializers in Wapi is not an easy task. So let's start explaining the basics. Class based approach (again) Serializations are specified as a class, which inherits from wapi.serializers.Serializer, defining multiple methods which return a dictionary. Every method is a serialization "preset", which you can specify at the time you serialize the objects. Let's see a brief example: from wapi.serializers import Serializer from wapi import serializers from notes.models import UserProfile class UserProfileSerializer(Serializer): serializes = UserProfile @serializers.objname('user') def default(self, obj, **kwargs): return { 'username': obj.user.username, 'display_name': obj.display_name, 'avatar32': obj.get_avatar_url(32), 'avatar128': obj.get_avatar_url(128), } As you see, we've defined a class with the serializes attribute. … -
Why I choose AGPLv3 for my code
From now, all the code for Django applications I'll be releasing will be under AGPLv3, which means every application using them will need to be under the same license (which requires your code to be available). You may be thinking why I'm doing this, so I'll give you an explanation. I've recently spotted some freeloaders in the Django community, and that's something I usually don't like. I understand that making your code available doesn't always makes sense, because sometimes your application is too vertical and the only ones benefiting from your code are the ones who are competing with you. But if you write something which could potentially benefit hundreds of sites which don't compete with you and you choose to make it closed source, then you're not going to get my code for free. Keep in mind that I'm not preventing you from building commercial products with my code, as long as you release your work under AGPLv3. I don't have any problems with people making money off my work, as long as they give something back. However, as I mentioned, sometimes I can understand your situation. If you want to use this code to build a non-AGPLv3 product, … -
Cited in Bangalore - How cool is that?
As Pradeep just pointed out in my Blog comments, he used parts of my posting on video blogging with Django (which is funnily enough always referenced as “Create your own YouTube site” - a claim I wouldn’t have dared make myself ) as basis/inspiration for a presentation at Bar Camp Bangalore. BarCamp describes [...] -
Amazed at Django
I spent this weekend working on a new portal site for which I had the idea a couple of days ago (yeah, I know — weekends are for something else; but it was absolutely freezing cold here in Germany, so I succumbed to my inner geek). I’m building the site using the Python Web framework [...] -
New travel portal opened: trogger.de
German-language travel site trogger.de opens. -
Django book completed. Congrats to Adrian and Jacob!
Jacob Kaplan-Moss posted to his blog yesterday that the Django book (Pro Django. Web Development Done Right) is completed and is now going off to the printers. He writes: “It should start shipping to bookstores around the second week of December.”This is great news! It’s great news for the Django platform — it’s a true [...] -
Inspiration for a RentaCoder listing
An interesting (well, to me anyway) tangent to my recent post about GetAFreelancer. While looking through my Google Analytics report, I just found a number of referrals from rentacoder.com. Looking further, I find that someone had been looking for a developer for build a solution for “Video Blogging using Django and Flash(tm) Video (FLV)”.If this [...] -
New Django installation
I just got a new machine, with x64 processor (Pentium D Dual Core — nice machine!) and naturally it’s already running Linux. SUSE 10, to be specific. Now I wanted to move my Django project over from the old machine and the Django installation kept failing. The setup.py told me: Installed /home/tietze/temp/Django-0.91 Because this distribution was installed [...] -
English version of trogger travel portal launched!
I just launched the English language version of my Django-powered travel portal, trogger.de. The newly-launched English version is at trogger.info. For those who haven’t yet checked out trogger, trogger is a travel-oriented Web community site, where users can maintain travel blogs, post travel reports, share holiday insider tips and publish photo albums. The most recent extension [...] -
Video Blogging using Django and Flash(tm) Video (FLV)
I just added Flash-based (FLV) video blogging support to my Django-powered travel portal site, trogger.de. The whole process is surprisingly simple and straightforward and can be done entirely with free (FLOSS) tools. The video publishing workflow consists of the following parts: A Django model to store our video and associated information An upload form where the user can [...] -
Extending the Django User model with inheritance
Update March 2013: Django 1.5 includes a configurable custom user model that makes all this obsolete. Extra fields for Users Most of the Django projects I’ve worked on need to store information about each user in addition to the standard name and email address held by the contrib.auth.models.User model. The old way: User Profiles The solution in the past was to create a “user profile” model which is associated 1-to-1 with the user. Something like: the model class UserProfile(models.Model): user = models.ForeignKey(User, unique=True, related_name='profile') timezone = models.CharField(max_length=50, default='Europe/London') config in settings.py AUTH_PROFILE_MODULE = 'accounts.UserProfile' usage profile = request.user.get_profile() print profile.timezone It works ok, but it’s an extra database query for each request that uses the profile (it’s cached during the request so each call to get_profile() is not a query). Also, the information about the user is stored in two separate models, so you need to display and update fields from both the User and the UserProfile models. The new way: Model Inheritance As part of the great work done on the queryset-refactor by Malcolm et al, Django now has model inheritance. If you’re using trunk as of revision 7477 (26th April 2008), your model classes can inherit from an … -
Decorating the Render Methods of New-Form Widgets
Perhaps all template masters have already faced the problem of styling HTML input fields of different types. The selectors like input[type=checkbox] and similar in CSS are not supported by IE so people working with templates and CSS obviously need some other way to select and style specific types of input fields.There are a few ugly ways to do that which violate the DRY principle:Encompassing the form element in the template with HTML tag which has a class representing specific type of the input field.For example:<span class="form_checkbox"> {{ form.is_privacy_policy_confirmed }}</span>Defining the specific CSS class for each form field widget in the form.For example:class FormExample(forms.Form): is_privacy_policy_confirmed = forms.BooleanField( required=True, widget=CheckboxInput(attrs={'class': 'form_checkbox'}), )Extending all Fields and all Widgets which use HTML input fields and using the extended versions instead of the originals. I don't like any of them, because they force me or the template formatters to repeat ourselves and make plenty of replacements in our existing forms.Although "most sane developers consider it a bad idea", I see the Guerrilla patching of the Widget's render method as the nicest solution to solve this problem.Guerrilla patch is the modification of the runtime code in dynamic languages without changing the original source code.The method render … -
Fret Free -- Introduction to Django and the Django Software Foundation
LinuxPro Magazine just released my latest article, an introduction to Django and some discussion about the newly created Django Software Foundation. Being a life long Perl user, I didn't think I would enjoy Django at all. I have to admit that it is a VERY polished system. It has great PostgreSQL support, in fact the core developers smartly prefer it over MySQL for their own systems. You can download a PDF copy of the article at, Fret Free -- Django and the Django Software Foundation. The print issue will hit the stands in October. Hope you enjoy it!