treibsand.com » Django

Ärger mit Generic Views von Django

Toast — Mon, 09 Mar 2009 10:16:12 +0000

Django ist ja eines der besten Frameworks für Python um schnell Webanwendungen zu realisieren. Allerdings ist es leider noch nicht so ausgereift wie z.B. Ruby on Rails. Die Generic Views von Django sind zwar sehr hilfreich, allerdings nicht ganz konsequent umgesetzt.

So gibt es bei den Views create\_object, update\_object und delete\_object die Möglichkeit login\_required zu übergeben, aber bei anderen Views wie z.B. direct\_to\_template nicht. Das ist ziemlich ärgerlich, da es hier genauso Sinn machen würde.

Allerdings gibt es einen kleinen Workaround…

from django.contrib.auth.decorators import login_required 
from django.views.generic.simple import direct_to_template
 
urlpatterns = patterns('',
	(r'^meineurl/$',login_required(direct_to_template),
		{'template':'welcome.html'}),
...

Dadurch erhält man das gleiche Ergebnis, wie wenn man login\_required als Argument dem View übergibt.

Mit Django Datenbank Tabellen ändern

Toast — Thu, 17 Apr 2008 15:40:30 +0000

…geht leider nicht. Ist ein Datenbank Model einmal definiert, lässt es sich nicht ohne Umwege erweitern. Ruby on Rails ist da schon ein Stück weiter.

Das Problem lässt sich aber mit einem kleinen Trick lösen. Mit Django hat man die Möglichkeit die komplette Datenbank serialisiert zu dumpen und anschliesend wieder zu laden. Die Vorgehensweise ist einfach, einen Dump vom Model bzw. der ganzen Datenbank machen, Model um die gewünschten Felder erweitern, DB Tabellen löschen, Tabellen mit syncdb neu anlegen und den Dump wieder einspielen.

Die komplette Datenbank kann mit

python manage.py dumpdata > mydump.json

gedumpt werden. Einzelne Models mit

python manage.py dumpdata MyModel > mydump.json

Das importieren des Dumps geht wie folgt:

python manage.py loaddata mydump.json

Will man aber z.B. eine Anwendung mit initialen Daten versorgen, dann kann das mit Fixtures gemacht werden. Hierfür ist ein Eintrag in der Settings Datei notwendig.

FIXTURE_DIRS = (
        '/absoluter/pfad/zum/fixtures/verzeichnis',
)

Liegt nun in diesem Verzeichnis eine Datei mit der Endung json, dann wird diese automatisch beim syncdb geladen und importiert.

Sitemaps mit Django erstellen

Toast — Sat, 12 Apr 2008 15:45:25 +0000

Eine Sitemap ist nichts weiter als eine XML Datei auf dem Webserver, welche Suchmaschinen sagt wie sich Seiten geändert haben, und wie wichtig einzelne Seiten sind. Ausserdem kann man so Seiten Suchmaschinen geben, die evtl. nicht in den Index aufgenommen werden.

Zum Glück nimmt Django einem die Arbeit ab, so dass Sitemaps automatisch erzeugt werden können. Die Installation ist ziemlich simpel:

Das Modul ‘django.contrib.sitemaps’ zu den INSTALLED_APPS hinzufügen
Sicherstellen, dass ‘django.template.loaders.app_directories.load_template_source’ in den Template Loaders eingetragen ist
Sicherstellen, dass das sites framework aktiviert ist

Danach sind nur noch wenige Einträge in der Datei urls.py zu machen…

from django.conf.urls.defaults import *
from django.contrib.sitemaps import FlatPageSitemap, GenericSitemap
from mysite.blog.models import Entry
 
info_dict = {
    'queryset': Entry.objects.all(),
    'date_field': 'pub_date',
}
 
sitemaps = {
    'flatpages': FlatPageSitemap,
    'blog': GenericSitemap(info_dict, priority=0.6),
}
 
urlpatterns = patterns('',
    # ...
    (r'^sitemap.xml$', 'django.contrib.sitemaps.views.sitemap', {'sitemaps': sitemaps})
)

Mehr ist nicht zu machen

Es ist sogar möglich, bei Aenderungen am Model Google zu pingen, so dass die Sitemaps neu eingelesen werden…

from django.contrib.sitemaps import ping_google
 
class Entry(models.Model):
    # ...
    def save(self):
        super(Entry, self).save()
        try:
            ping_google()
        except Exception:
            # Bare 'except' because we could get a variety
            # of HTTP-related exceptions.
            pass

Mit Django JSON ausliefern

Toast — Thu, 14 Feb 2008 14:50:27 +0000

Dank den neuen JavaScript Frameworks wie z.B. Prototype und MochiKit ist es mittlerweile ziemlich einfach dynamische Webinhalte mit AJAX zu machen.

Doch die Daten müssen erstmal in die passende Form gebracht werden, um verarbeitet werden zu können. Eine Möglichkeit ist JSON (JavaScript Object Notation).

Dank Djano kann das auch sehr einfach werden. Um zum Beispiel alle Einträge aus den Feldern “name” und “size” einer Tabelle mit JSON bereitzustellen reicht folgender Code aus:

from someproject.someapp.models import SomeModel
from django.http import HttpResponse
from django.core import serializers
 
def json(request,):
  data = serializers.serialize('json', SomeModel.objects.all(), fields=('name','size'))
  return HttpResponse(data, mimetype="text/plain")

Und schon kann man per URL JSON Daten abfragen. Happy coding!

Shortcut Decorator

Toast — Fri, 25 Aug 2006 19:15:27 +0000

Ist es nicht manchmal nervig bei Django in views render_to_response aufzurufen, und gegf. sogar noch den Context? Vor kurzem brauchte ich den Template Processor django.core.context_processors.auth, um auf die Session Variable “user” zuzugreifen

In generic views ist dies ja bereits automatisch der fall, dass die Variable im Template verfuegbar ist. Bei normalen views muss man allerdings jeweils den richtigen Context angeben, wie z.B. mit

def myview(request):
  ...
  return render_to_response("template.html",
    context_instance=RequestContext(request))

Das kann mit der Zeit ziemlich nervig werden. Mit folgendem Decorator kann man sich das Leben erheblich leichert machen:

from django.template.context import RequestContext
from django.http import HttpResponse
from django.shortcuts import render_to_response
 
def page(template=None, **decorator_args):
  def _wrapper(fn):
    def _innerWrapper(request, *args, **kw):
      context_dict = decorator_args.copy()
      g = fn(request, *args, **kw)
      if not hasattr(g, 'next'): 
        g = (g,)
        for i in g:
          if isinstance(i, HttpResponse):
            return i
          if type(i) == type(()):
            context_dict[i[0]] = i[1]
          else:
            context_dict.update(i)
        template_name = context_dict.get("template",  template)
        context_instance = RequestContext(request)
        return render_to_response(template_name, context_dict, context_instance)
    return _innerWrapper
  return _wrapper

Dadurch kann man bei einem view per Decorator direkt das Template angeben, ohne render_to_response aufzrufen:

@page("template.html")
def myview(request):
  somedata = Data.objects.all()
  yield {'data': somedata}

Aber das ist noch nicht alles…

@page("template.html", title="Titel der Seite") # extra Argument fuer den Context
def myview(request):
  somedata = Data.objects.all()
  yield locals() # lokale Variable werden an den Context uebergeben, in  diesem Fall somedata

Das Template muss auch nicht umbedingt im Decorator angegeben werden…

@page()
def myview(request):
  somedata = Data.objects.all()
  template = "template2.html"
  yield locals() # lokale Variable werden an den Context uebergeben, in  diesem Fall somedata

Cool oder?

Django über CGI ausliefern

Toast — Thu, 03 Aug 2006 15:22:17 +0000

Eigentlich ist ja die bevorzugte Methode, um Django Anwendungen auszuliefern, mod_python. Allerdings kann man teilweise nicht immer mod_python verwenden, z.B. wenn der Provider dies nicht unterstützt. Genau das gleiche gilt z.B. auch für FastCGI. Da Django selber WSGI kompatibel ist, ist es auch möglich Django über CGI auszuliefern.

Hierfür braucht man allerdings natürlich ein CGI Script, was die Server Komponente von FastCGI bzw. mod_python ersetzt. Ausserdem muss der Apache ein wenig angepasst werden, was auch in einer .htaccess Datei gemacht werden kann.

#!/usr/bin/env python
 
import os, sys
from django.core.handlers.wsgi import WSGIHandler
from django.core.servers.basehttp import ServerHandler
 
class CGIHandler (ServerHandler) :
	origin_server = False
	default_settings_module = "settings"
	status = "500"
 
	def __init__ (self, environ, *path):
		sys.path.extend (path)
		key = "DJANGO_SETTINGS_MODULE"
		if key not in environ :
			environ [key]    = self.default_settings_module
		self.request_handler = self
		super (CGIHandler, self).__init__ (
			sys.stdin, sys.stdout, sys.stderr, environ,
			multithread  = False,
			multiprocess = False
		)
 
	def run (self, cls):
		super (CGIHandler, self).run (cls ())
 
	def log_request (self, status, bytes):
		pass
 
CGIHandler(
	os.environ,
	"/pfad/zum/projekt"
).run (WSGIHandler)

Das CGI Script kann z.B. so aussehen Das Script heisst bei mir django.cgi und liegt direkt im Projekt Ordner. Falls die Environment Variable DJANGO_SETTINGS_MODULE gesetzt ist, dann wird diese auch verwendet, ansonsten wird die Datei settings.py im Projekt Ordner verwendet.

Die Konfiguration von Apache ist jetzt nicht mehr schwer:

AliasMatch ^/MYAPP(.*) /pfad/zum/projekt/django.cgi/MYAPP$1
 
  AddHandler  cgi-script .cgi
  Options ExecCGI

Diese Anweisungen bewirken, dass alle Anfragen für http://domain/MYAPP von der Datei django.cgi abgewickelt werden. Es wurde erst vor kurzem ein Ticket aufgemacht, mit welchem ein CGI Handler zu Django hinzugefügt wird. Allerdings kann das wohl noch eine Weile dauern, bis dies wirklich eingebaut ist.