What's new in Django community blogs?

Django domain redirect middleware

Dec 26 2007 [Archived Version] □ Published at Ikke's blog under tags  development django

Most web developers know it’s possible to serve one site on several domains or subdomains, using eg. the ServerAlias Apache directive. Sometimes this behaviour is not wanted: you want your main domain to be “foo.tld”, although “www.foo.tld” should work too, and maybe even some completely different domains. This way it’s possible to have permalinks, and [...]


Two Django snippets

Dec 26 2007 [Archived Version] □ Published at Ikke's blog under tags  development django

Last 2-3 days I’ve been working on this new site project. As (almost) all web projects I started last 2 years, I’m using the Django framework to develop the site, as I just love it for several reasons. Tonight I’d like to share 2 snippets. The first one is one I use quite regularly. It’s [...]


Django, paths and URLs

Dec 22 2007 [Archived Version] □ Published at Occasionally sane under tags  django

Michael Trier has a blog post on how he keeps his Django projects portable from one directory to another. This is something that gave us a hard time at work too and that we managed to fix (differently.) To give … Continue reading


Django, paths and URLs

Dec 22 2007 [Archived Version] □ Published at Occasionally sane under tags  django

Michael Trier has a blog post on how he keeps his Django projects portable from one directory to another. This is something that gave us a hard time at work too and that we managed to fix (differently.) To give … Continue reading


Picture gallery using MooTools

Dec 20 2007 [Archived Version] □ Published at zoe.vc under tags  aero cool effect gallery image

After dealing with Windows Vista some time ago there was this idea about creating an image gallery for the web that looks like the tab view in vista using the aero user interface. First you could think about creating this with flash but it's also possible with javascript and the mootools framework. It took a long time until it worked properly for putting it into the web, mainly because there was rarely time working on it.

I created an extra page for the script that answers to the name of "ImageFlip" because I'll continue working on it. If you have any questions, ask me here or write an email as specified on the page:

ImageFlip 0.1

to the ImageFlip minpage....


Picture gallery using MooTools

Dec 20 2007 [Archived Version] □ Published at zoe.vc under tags  aero cool effect gallery image

After dealing with Windows Vista some time ago there was this idea about creating an image gallery for the web that looks like the tab view in vista using the aero user interface. First you could think about creating this with flash but it's also possible with javascript and the mootools framework. It took a long time until it worked properly for putting it into the web, mainly because there was rarely time working on it.

I created an extra page for the script that answers to the name of "ImageFlip" because I'll continue working on it. If you have any questions, ask me here or write an email as specified on the page:

ImageFlip 0.1

to the ImageFlip minpage....


2008 Digital Edge Award Finalists

Dec 20 2007 [Archived Version] □ Published at Matt Croydon under tags  django journalism

The 2008 DIgital Edge Award finalists were just announced, and I’m excited to see several World Company sites and projects on there as well as a couple of sites running Ellington and even the absolutely awesome Django-powered PolitiFact.com. At work we don’t do what we do for awards. We do it to serve our readers, […]


Django Template Tag for Dictionary Access

Dec 19 2007 [Archived Version] □ Published at Push cx under tags  code dictionaries django hash templates

About a million times when writing Django pages I’ve been iterating through a list of objects and wanted to look up a value in a dictionary keyed by object.id. But you can’t, the built-in tags don’t allow it. The standard workaround is to loop over the list and zip the hash data into some kind […]


Django Template Tag for Dictionary Access

Dec 19 2007 [Archived Version] □ Published at Push cx under tags  code dictionaries django hash templates

About a million times when writing Django pages I’ve been iterating through a list of objects and wanted to look up a value in a dictionary keyed by object.id. But you can’t, the built-in tags don’t allow it. The standard workaround is to loop over the list and zip the hash data into some kind […]


Creating a Pownce Widget Using Django

Dec 18 2007 [Archived Version] □ Published at Eric Florenzano's Blog

Creating a Pownce Widget Using Django

Dec 18, 2007

Widgets are everywhere! It seems that every blog these days has at least a couple of widgets on their sidebar. Yesterday I realized that I had never written one, and probably more importantly, I really had no concrete idea how they worked. Using Django and a bit of Javascript, it turned out to be quite easy! I'm going to show you the basics of how to write a widget yourself, but if enough people would like the source code to mine, I'll happily open source it.

Before starting on creating a widget, we've got to make sure that it has an API of some sort. In the case of Pownce, there some Community Documentation about the various things that can be done with its API. For a simple widget, all we really need is to be able to fetch some public notes.

Our API call will be: http://api.pownce.com/1.1/public_note_lists.json

Now that we've determined where to get our data, let's parse it and do something with it.

from urllib2 import urlopen
from django.utils import simplejson
from django.template import loader, Context
from django.http import HttpResponse
def pownce_widget(request):
    api_call = "http://api.pownce.com/1.1/public_note_lists.json"
    notes = simplejson.loads(urlopen(api_call).read())['notes']
    t = loader.get_template('powncewidget/widget_content.html')
    c = Context({'notes' : notes})
    return HttpResponse(t.render(c))

Now you may be noticing that I'm not using the simpler django.shortcuts.render_to_response. That's because we're going to use the content that we've rendered here as context for another template which we'll use in a moment. Also note that if you were to do this in a production environment, using a simple urlopen is not considered good practice. See chapter 11 in Mark Pilgrim's excellent Dive Into Python for more information about what to do instead.

Now let's create a template:

<ul id="pownce_widget">
    {% for note in notes %}
        <li><a href="{{ note.permalink }}">{{ note.body|slice:":30" }}</a></li>
    {% endfor %}
</ul>

What we've done here is iterated over the public notes, and simply created an unordered list with the first 30 or less words from the note. Also, we've provided a link to Pownce for each note listed.

If browsers could make cross-domain requests, we'd be done now: you could embed a small Javascript file which would asynchronously request this page and update the DOM accordingly. However, this is not possible, so I've come up with a way to do it instead. I'm not sure if it's a best practice--it sure seems to me like it's not--but it works, which is probably more important anyway.

So let's modify our view:

from urllib2 import urlopen
from django.utils import simplejson
from django.template import loader, Context, RequestContext
from django.http import HttpResponse
from django.shortcuts import render_to_response
def pownce_widget(request):
    api_call = "http://api.pownce.com/1.1/public_note_lists"
    notes = simplejson.loads(urlopen(api_call).read())['notes']
    t = loader.get_template('powncewidget/widget_content.html')
    c = Context({'notes' : notes})
    context = {"widget_content" : t.render(c))}
    return render_to_response("powncewidget/widget.html", context, context_instance=RequestContext(request))

We've taken the rendered output from widget_content.html and used it as context for another template, widget.html, which we return as an HttpResponse to the browser. This doesn't make much sense until we've seen what that widget.html template contains. Here it is:

{% load stripwhitespace %}

var _cssNode = document.createElement('link');
_cssNode.type = 'text/css';
_cssNode.rel = 'stylesheet';
_cssNode.href = '{{ MEDIA_URL }}css/powncewidgetstyle.css';
_cssNode.media = 'screen';
document.getElementsByTagName("head")[0].appendChild(cssNode);
document.write('{{ widget_content|stripwhitespace|safe }}');

What we're doing here is dynamically creating Javascript using Django's templating system which injects your rendered HTML into the page. The first few lines add a new stylesheet to the page, and the last one writes your content to the page. But what is this stripwhitespace filter that we see? Javascript does not like multi-line string declarations such as what widget_content produces. With Django, it's easy to write a simple filter to make it all exist on one line:

from django import template
import re
inbetween = re.compile('>[ \r\n]+<')
newlines = re.compile('\r|\n')
register = template.Library()
def stripwhitespace(value):
    return newlines.sub('', inbetween.sub('><', value))
register.filter('stripwhitespace', stripwhitespace)

With that, we've pretty much finished up on creating our widget. There are lots of customization options from here: GET arguments, different API endpoints, etc. Not only that, but there's lots of room for visual customization using CSS. What we're doing is effectively generating Javascript, so anything that you'd like to do using Javascript is fair game as well.

The result after tweaking for a bit is what you see at the right under my "Widgets" links. Here is a picture in case it stops working for some reason:

http://media.eflorenzano.com/img/powncesample.png

If you'd like to create a pownce widget of your own by simply adding a snippet to your site, I've provided a Pownce Widget Creator for your convenience.

I think that it was fairly easy to do this using Django and Python, and if you've got any tips on best practices, please let me know so that I can code a better widget!


Django internationalisation

Dec 17 2007 [Archived Version] □ Published at Blog Roll under tags  django internationalisation online survey

Multilingual web site with django

I have been recently working on a web application that needs to support several languages, English and French among others. This web application is built on top of Django which has a nice built in support for internationalisation, also known as i18n. However along the road of building this web application I have noticed some gaps between what was existing and what I was trying to achieve.

Here it is the list whithout any particular order:
- a multilingual flatpages
- a way to explicitely use display the language code (ie fr for French and en for English) directly in the URL. I do prefer http://yml.alwaysdata.net/fr/help instead of http://yml.alwaysdata.net/ and rely on the browser settings to direct my user the right page. In addition I have the feeling that this would result in a much better indexation by search engine like Google or Yahoo, ...
- a simple UI to set the language.

The good news is that after some time, search and chat on IRC I have found a way to close all of them.

Multilingual flatpages
This has been amazingly simple thanks to django-multilingual, a library kindly developped by ???. In a matter of one or two hours I have forked "django.contrib.flatpages" and adapted it to support my specific needs. The new django application is name django multilingual and is available there . This might be integrated as battery inside django-multilingual library in the future. This application is fairly simple and intuitive to use once it is installed you can start adding you multilingual flatpages directly in "admin". For each multilingual flatpage you will be able to write a title and a content per language in my case french and english. You can see this application live there : http://yml.alwaysdata.net

Language code explicit in the URL

I found a nice post there presenting a solution closing that gap, unfortunately I am unable to find the link again. The proposal is to add a middleware that intercept the request and proceed to the following operations:
* detect the language code in the URL
* Force the language to the one specified in the URL
* remove the language code from the URL this allows you to use your urls.py unchanged

[code] --- with the indentation

from django.utils.cache import patch_vary_headers
from django.utils import translation

class MultilingualURLMiddleware:
def get_language_from_request (self,request):
from django.conf import settings
import re
supported = dict(settings.LANGUAGES)
lang = settings.LANGUAGE_CODE[:2]
check = re.match(r"/(\w\w)/.*", request.path)
changed = False
if check is not None:
request.path = request.path[3:]
t = check.group(1)
if t in supported:
lang = t
if hasattr(request, "session"):
request.session["django_language"] = lang
else:
response.set_cookie("django_language", lang)
changed = True
if not changed:
if hasattr(request, "session"):
lang = request.session.get("django_language", None)
if lang in supported and lang is not None:
return lang
else:
lang = request.COOKIES.get("django_language", None)
if lang in supported and lang is not None:
return lang
return lang
def process_request(self, request):
from django.conf import settings
language = self.get_language_from_request(request)
if language is None:
language = settings.LANGUAGE_CODE[:2]
translation.activate(language)
request.LANGUAGE_CODE = translation.get_language()
def process_response(self, request, response):
patch_vary_headers(response, ("Accept-Language",))
translation.deactivate()
return response

[/code]

A simple UI to select the language

As of today I am using a set of dynamicaly generated URLs but I might change this in the future to use a form instead. This is fairly simple as soon as you know all the pieces. :-)

[code]

{%trans "Set your language" %}


|
{% for language in LANGUAGES %}
{% ifequal LANGUAGE_CODE language.0 %}
{{language.1}}|
{% else %}
{{ language.1 }}|
{% endifequal %}
{% endfor %}

[/code]

As you have seen most of bricks I had to use to implement my multilingual web application were available out there on the internet. After all multilingual web application is not something new, but I was a bit surprised not to find any ready to use library suiting my requirements. Several reasons could explain this:
* I had some very unique requirements
* What I did was so simple that my expectation was to high
* I missed something important
* I should not have done it that way

I would be glad hear your opinion if you have one. I am sure that the solution presented there can be enhanced do not hesitate to post a comment on that blog to let me know how. :-)

PS1: You are free to copy, modify the code posted on this blog.
PS2: Does someone know how to fix the code indentation on blogger.com?


“AttributeError: ‘module’ object has no attribute ‘blah’”

Dec 12 2007 [Archived Version] □ Published at Rachel's Knowledge Base under tags  django python

The obvious cause of this is that the settings.py doesn’t have the directory containing blah listed in INSTALLED_APPS. A less obvious cause: you’ll also get this error if the directory doesn’t contain a file __init__.py.

The post “AttributeError: ‘module’ object has no attribute ‘blah’” appeared first on Rachel's Knowledge Base.


Django-Related Audio from Last Year's PyCon

Dec 11 2007 [Archived Version] □ Published at Eric Florenzano's Blog

Django-Related Audio from Last Year's PyCon

Dec 11, 2007

I was lucky enough to be able to attend PyCon last year, and hope to do so again, but some great resources are starting to show up online for those who couldn't. One example is Jacob Kaplan-Moss's talk named Becoming an Open Source Developer: Lessons from the Django Project.

Even if you've read James Bennett's excellent writeup from the conference, some audio from the event itself can always be fun to listen to. Right now that's all I could find, but there's new audio showing up from PyCon every week. The only way to stay updated is to subscribe to the PyCon 2007 Podcast RSS Feed.

P.S. Hello Django community aggregator!

Posted in:


Two-Faced Django Part 5: JQuery Ajax

Dec 11 2007 [Archived Version] □ Published at Irrational Exuberance

We've been spending a lot of time together recently, and you're probably wondering if I'm going to quit writing this series before covering any Ajax at all. That is a very valid concern. But, be reassured, this segment of the tutorial is going to cover using JQuery to implement Ajax voting in our web app. If you haven't followed along with the previous articles, grab the snapshot of the current progress of our project.

Adding JQuery to the web app

The first thing we need to do is download JQuery. I recommend grabbing the uncompressed version, because it makes debugging things much more pleasant when you don't have to read minified Javascript...

var x = m45(k32, a32);
n41(x);

What does that mean? I don't have the faintest clue. But if you want to find out, you can get the gzipped and minified library version instead of the uncompressed library linked to above.

Once you have downloaded the library, you're going to want to move it into the polling/media/web/ folder. For sake of simplicity we are going to rename it to "jquery.js".

mv jquery-1.2.1.js jquery.js

Now we just need to modify our polling/templates/web/base.html file to import the JQuery library. First open up our file

emacs templates/web/base.html

Now we want to change the top of the template from

<html> <head>
<title>{% block title %}A Generic Title{% endblock %}</title>
</head>

to

<html> <head>
<script type="text/javascript" src="/media/web/jquery.js"></script>
<title>{% block title %}A Generic Title{% endblock %}</title>
</head>

One task crossed off the todo list. A handful more to go.

Adding URLs for the Ajax.

Go ahead and open up the urls.py for the web app. Its sleeping at polling/web/urls.py.

emacs web/urls.py

When designing your urls, you might decide that you'd want something that looks like this:

(r'^poll/(?P<id>\d+)/vote/up/$', 'polling.web.views.vote_up'),
(r'^poll/(?P<id>\d+)/vote/down/$', 'polling.web.views.down_down'),

So you'd send an Ajax (although, I really just mean asyncronous) request to /poll/4/vote/up/ to vote up poll 4, and you'd send an Ajax request to /poll/13/vote/down/ to vote down poll 13. Thats a perfectly reasonable way to structure your urls.

In this tutorial we're going to do it this way instead:

(r'^vote/$', 'polling.web.views.vote'),

We're not going to rely less on the url requested, and rely more on the GET parameters passed along with the request. Why is this better? Well, it does let us write one view instead of two views (although that one view will be more complex than the two views), but the real benefit here is a bit contrived: it gives us the opportunity to showcase rewriting javascript snippets with Django templates.

Your web/urls.py should look like this now:

from django.conf.urls.defaults import *
from polling.core.models import *
polls = Poll.objects.all()
urlpatterns = patterns('',
    (r'^$', 'django.views.generic.list_detail.object_list',
     dict(template_name='web/poll_list.html', queryset=polls)),
    (r'^poll/(?P<object_id>\d+)/$', 'django.views.generic.list_detail.object_detail',
     dict(template_name='web/poll_detail.html', queryset=polls)),
    (r'^create/$', 'polling.web.views.create'),
    (r'^vote/$', 'polling.web.views.vote')
)

Now we need to write that pesky vote view in the web/views.py file.

Writing the vote view

A little bit back I mentioned that we are going to be communicating with the vote view using data sent via GET requests. The first thing we need to pin down is what data will we be expecting, and how will we label it?

We need two pieces of data:

  1. the primary key of the poll to vote on, and
  2. whether it is an up vote or a down vote.

Because I possess a simple mind, we're going to translate those requirements into two keys: 'pk' and 'vote', and we're expecting 'pk' to be an integer representing the poll's primary key, and we're going to expect the value of 'vote' to be either 'up' or 'down'.

After that highly democratic design session, we're ready to start writing our view. First thing we need to open up the web/views.py file.

emacs web/views.py

The first thing we need to do is add an import for simplejson:

from django.utils import simplejson

and change the line importing HttpResponseRedirect from

from django.http import HttpResponseRedirect

to

from django.http import HttpResponse, HttpResponseRedirect

Now we need to write our vote view. Lets plan how it should work before we look at the code:

  1. Check if the request is of type GET.
  2. If not of type GET, fail.
  3. If is of type GET, check for existance of parameters 'pk' and 'vote'.
  4. If one or both parameters does not exist, fail.
  5. If both exist, grab the corresponding poll and vote up or down depending on the value of 'vote'.

Okay, now lets see how it looks in Python.

def vote(request):
    results = {'success':False}
    if request.method == u'GET':
        GET = request.GET
        if GET.has_key(u'pk') and GET.has_key(u'vote'):
            pk = int(GET[u'pk'])
            vote = GET[u'vote']
            poll = Poll.objects.get(pk=pk)
            if vote == u"up":
                poll.up()
            elif vote == u"down":
                poll.down()
            results = {'success':True}
    json = simplejson.dumps(results)
    return HttpResponse(json, mimetype='application/json')

The first thing you'll notice is that we're making a default value for result in the first line of our function. This isn't necessary, but it means we only have to set it in one place, and also means we only have one exit from the function (which makes it easier to follow the logic of the function, and easier to debug if things start going wrong).

The next thing you'll notice (because.. its the second line) is:

if request.method == u'GET':

That is the approved Django way for determining the type of the request you are dealing with. The other situation you'll see this used is when dealing with POSTs (we actually did that in the last segment of the tutorial when writing the view for creating new polls).

Notice that we use the *has_key()* method to check that the QuerySet (a Django class that is similar to, but slightly quickier than, a Python dictionary) for the two keys we care about 'pk' and 'vote'. The last two things I'll mention are that we're using unicode strings everywhere here, this is because Django uses unicode strings internally now, so everything you'll be comparing with will be unicode. Since you're apps are likely to run into non-ascii data at some point, it just makes sense to use unicode everywhere.

The last bit is about simplejson. Simplejson is a library for serializing basic Python structures into JSON, and thus makes it the easiest way to communicate with Javascript. The simplejson.dumps() function takes a basic Python structure, and returns a string representing it as JSON.

Okay. And thats it for our view. Now we just need to inject some JQuery javascript into one of our templates and we'll be finished.

Using JQuery for voting

Now we just need to write a few lines of javascript using JQuery to avoid most nastiness. Go ahead and open up the polling/templates/web/poll_detail.html.

emacs templates/web/poll_detail.html

Now we're going to go ahead and inline a few lines of javascript (I put it directly above the paragraph with the spans whose id's are 'upvote' and 'downvote').

<script>
function vote(kind) {
  $.getJSON("/vote/", { pk:{{ object.pk }}, vote: kind }, function(json){
    alert("Was successful?: " + json['success']);
  });
}
function addClickHandlers() {
  $("#upvote").click( function() { vote("up") });
  $("#downvote").click( function() { vote("down") });
}
$(document).ready(addClickHandlers);
</script>

The vote() function is used to vote up or down, notice how we create a hashmap (similar to a Python dictionary) containing the values 'pk' and 'vote'. Those are the parameters passed along with our GET request to our Django server at the '/vote/' url. The most interesting part there is the {{ object.pk }} segment. There we are using the Django templating language to modify our Javascript on the fly. A handy trick.

Other interesting bits in no particular order:

  • $("#upvote") is how JQuery selects the element with id 'upvote'
  • $(document).ready(callThisFunc); is a trick that JQuery uses to load Javascript once the dom elements in the webpage have been created (in English: to call Javascript when the html elements actually exist to be modified).
  • $("someelement").click(callThisFunc); Instead of using the standard Javascript ele.onclick = someFunc, JQuery passes a function as an argument to the click function. This is a continuation of the JQuery concept that you should always have useful values returned by functions, and thus you can chain calls together.

Okay. So, altogether our templates/web/poll_detail.html should look like this:

{% extends "web/base.html" %}
{% block title %} Poll: {{ object.question }} {% endblock %}
{% block body %}
<div id="poll">
  <p>We have a question for you. {{ object.question }}
  <p> So far we have {{ object.up_votes }} upvotes and {{ object.down_votes }} downvotes, for an overall vote of {{ object.score }}! </p>
  <script>
  function vote(kind) {
    $.getJSON("/vote/", { pk:{{ object.pk }}, vote: kind }, function(json){
      alert("Was successful?: " + json['success']);
    });
  }
  function addClickHandlers() {
    $("#upvote").click( function() { vote("up") });
    $("#downvote").click( function() { vote("down") });
 }
 $(document).ready(addClickHandlers);
  </script>
  <p> Do you <span id="upvote">agree</span> or <span id="downvote">disagree</span>? </p>
</div>
{% endblock %}

And, now we just need to make sure it works, and then we're done.

Verifying our progress

First, lets fire up the development server:

python manage.py runserver

And then navigate to the list of polls (unless you haven't created any polls yet, then go here to create a poll first. Click on any of the polls, and you shold get transported to the detail page for that poll.

Now click on the text near the bottom of the screen labeled agree or disagree. It should then popup a javascript alert saying something like "Was successful?: True". If you look at our piece of Javascript above, you can notice that JQuery is deserializing the returned JSON array, and we are checking it for the 'success' key (which we are returning via our vote view in polling/web/views.py).

The score won't actively update in this screen, you'll need to return to the list of polls to see the updated scores. (If anyone runs into trouble figuring out how to dynamically update the page, I can write another segment covering that, but it'll require at least one actual request. :) A snapshot of our current code can be downloaded here.

And, we that we are done with the web app. Phew. We just need to start writing the PyFacebook app now, in section six of the tutorial.

By the way, writing tests for the create view in web/views.py is a really good idea. I'll leave that as an exercise for the reader, but hopefully I'll come back and walkthrough that as well.


Looking Forward: Upcoming Django Developments Worth Waiting For

Dec 10 2007 [Archived Version] □ Published at Eric Florenzano's Blog

Looking Forward: Upcoming Django Developments Worth Waiting For

Dec 10, 2007

  1. Newforms-Admin

    Started soon after the newforms package started to become stable, the newforms-admin branch allows for a much more modular and flexible admin application. The amount of flexibility allowed in this branch extends to permissions, allowing for user-defined permissions schemes--can you say 'row-level permissions'? It's even flexible enough to require no permissions at all: I needed a quick display interface for work this past summer, and I used some of the hooks in the newforms-admin branch to disable login and permissions and simply display some data publicly.

    Also, multiple different admin interfaces are easy with newforms-admin. Group your apps into functional sets and give each functional set its own admin interface. Those who are using this branch know that once you've gone newforms-admin, you'll never go back!

  2. GeoDjango

    This one flew under my radar until very recently. Their stated goal is "to make it as easy as possible to build GIS web applications and harness the power of spatially enabled data." These guys have done some really amazing things with this branch, including linking of the geographic data to cool widgets that can be displayed in the admin interface (think google maps, openlayers, and more to come as time goes on). I don't personally have a need for any of the capabilities being added in this project, but the scope and quality of what is being produced is impressive to say the least.

  3. Queryset-Refactoring

    As code grows and evolves, it's difficult to stop at a certain point and say, "this code doesn't fit the bill anymore." Malcolm Tredinnick was the one who stopped and said it. Already at this stage, many many bugs have been fixed by this branch. Queryset-refactoring is not just for fixing bugs. Once it's completed, database backends will have a much easier time of customizing their generated SQL. With each change like this, Django becomes more modular.

  4. Manually-Specified Intermediary Model Support

    OK I'm biased on this one. This is the patch that I've been working on lately. It's because every time I create an Django application, I start out with a ManyToManyField and end up breaking that off into a separate model. Once that's done, I have to change all of my code so that it doesn't use the convenient ManyToManyField helpers. Once this patch is complete, you'll be able to specify an intermediary model which will act as the storage for your m2m data. In this way, extra information can be attached to each relationship.

  5. Fixing app_label

    We're entering into 2008 soon, and that will mean that Django has been public for over two years. Some of the core developers have been using it internally for even longer than that. So one of the things which people have started running into, is that app_labels have started clashing. There hasn't been any definitive decision on how to avoid these clashes, but there have been several promising proposals. In any case, expect this functionality to change somewhat in the next few months, so that 'ellington.search' can coexist alongside 'chicagocrime.search'. No longer will you have to worry about naming everything differently!

These are just a few of the developments that are going on which seem interesting and promising. I hope that each and every one of these developing features eventually makes it into trunk, so that everyone can benefit from the hard work that people have put into the project. Also, if you've got a feature that you're excited about, let me know through the comments.

Posted in:


django-planet aggregates posts from Django-related blogs. It is not affiliated with or endorsed by the Django Project.

Social Sharing

Feeds

Tag cloud

admin administration adsense advanced ajax amazon angular angularjs apache api app appengine app engine apple application security aprendiendo python architecture argentina articles asides audrey aurelia australia authentication automation backup bash basics best practices big data binary bitbucket blog blog action day blogging book books buildout business c++ cache capoeira celery celerycam celerycrawler challenges chat cheatsheet cherokee choices christianity class-based-views cliff clojure cloud cms code codeship codeship news coding command community computer computers computing configuration consumernotebook consumer-notebook continuous deployment continuous integration cookiecutter couchdb coverage css custom d data database databases db debian debugging deploy deployment deployment academy design developers development devops digitalocean django django1.7 django admin django cms djangocon django framework django-nose django-readonly-site django-rest-framework django-tagging django templates django-twisted-chat django web framework tutorials documentation dojango dojo dotcloud dreamhost dughh easy_install eclipse education elasticsearch email encoding english error europe eventbrite events expressjs extensions fabric facebook family fashiolista fedora field file filter fix flash flask foreman form forms frameworks friends fun functional reactive programming gae gallery games geek general gentoo gis git github gmail gnome goals google google app engine guides gunicorn hack hackathon hacking hamburg haskell heroku holidays hosting howto how-to howtos how-tos html http i18n igalia image imaging indifex install installation intermediate internet ios iphone java javascript jinja2 jobs journalism jquery json justmigrated kde la latex linear regression linkedin linode linux login mac machine learning mac os x markdown math memcached meme mercurial meta meteor migration mirror misc model models mod_wsgi mongodb months mozilla multi-language mvc mysql nasa nelenschuurmans newforms news nginx nodejs nosql oauth ogólne openshift opensource open source open-source openstack operations orm osx os x ottawa paas packages packaging patterns pedantics pelican penetration test performance personal personal and misc philippines philosophy php pi pil pinax pip piston planet plone plugin pony postgis postgres postgresql ppoftw presentation private programmieren programming programming &amp; internet project projects pycharm pycon pycon-2013-guide pydiversity pygrunn pyladies pypi pypy pyramid python python3 queryset quick tips quora rabbitmq rails rant ratnadeep debnath reactjs recipe redis refactor release request resolutions rest reusable app review rhel rtnpro ruby ruby on rails scala scaling science screencast script scripting security server setup shell simple smiley snaking software software collections software development south sphinx sprint sql ssh ssl static storage supervisor support svn sysadmin tag tag cloud talk nerdy to me tastypie tdd techblog technical technology template templates template tags test testing tests tip tips tools tornado training transifex travel travel tips for geeks tumbles tutorial tutorials twisted twitter twoscoops typo3 ubuntu uncategorized unicode unittest unix use user authentication usergroup uwsgi uxebu vagrant validation virtualenv virtualenvwrapper web web 2.0 web application web applications web design &amp; development webdev web development webfaction web framework websockets whoosh windows wordpress work workshop wsgi yada year-end-review znc zope