Wangoo

Um die Session Variabel auch im Template direkt benutzen zu können gibt es zwei Varianten.

Variante 1:
Man fügt in der settings.py unter TEMPLATE_CONTEXT_PROCESSORS den Eintrag django.core.context_processors.request hinzu:

TEMPLATE_CONTEXT_PROCESSORS = (
"django.core.context_processors.auth",
"django.core.context_processors.debug",
"django.core.context_processors.i18n",
"django.core.context_processors.media",
'django.core.context_processors.request',
)

Dann kann man z. B. Session Daten aus dem request im Template mit

    {{ request.session }}

benutzen.

Variante 2:

Alternativ kann man eine “schlankere” Variante benutzen falls man nicht alles bzw. nur ein Teil der request Daten benötigt – wie bei mir – nur die Session Variabel. Dazu erstellen wir im Projektverzeichnis die Datei context.py.

context.py:

def add_session(request):
    return {'session': request.session}

settings.py:

TEMPLATE_CONTEXT_PROCESSORS = (
   "django.contrib.auth.context_processors.auth",
   "django.core.context_processors.debug",
   "django.core.context_processors.i18n",
   "django.core.context_processors.media",
   "django.contrib.messages.context_processors.messages"
   "context.add_session",
)

Und schon kann man im Template auf die Session Daten zugreifen.

   {{ session.variablenname }}

Optimal ist diese Variante um ggf. eigene Daten per Default im Template verfügbar zu machen.

Für einen Kunden habe ich ein Django Projekt erstellt welches er selber hosten möchte. Nach langem Suchen nach einem geeigneten und preiswerten Provider bin ich auf den Cloud-On-Demand Server von DomainFactory mit dem namen JiffyBox gestoßen.

Mehr…

Wer viel mit Dateisystemen in Python zu tun hat – kennt den Ärger mit den verschiedenen Implementierungen – benutzt man nun das mitgelieferte – benutzt man andere Libs, welche Lib für welchen Zweck …

Mit PyFilesystem ist es wesentlich einfacher:

Amazon S3 support and Secure FTP, and some pretty cool features such as FUSE support and Django storage integration.

Die Django-Storage integration werde ich mir mal bei Gelegenheit ansehen.

Echt klasse ist das Codebeispiel wie man ein RAMDRIVE mit nur 6 Zeilen Code erstellt:

from fs.osfs import OSFS
from fs.memoryfs import MemoryFS
from fs.expose import fuse

home_fs = OSFS('~/')
home_fs.makedir('ramdrive', allow_recreate=True)
fuse.mount(MemoryFS(), home_fs.getsyspath('ramdrive'))

Screencast und mehr auf dem Blog des Entwicklers: willmcgigan.com

Ich habe seit einiger Zeit die Signals von Django im Auge und wollte diese immer schonmal ausprobieren. Einfach aus Neugierde an der Sache. Aktuell habe ich ein Projekt wo man dies gut verwenden könnte.

Nachdem die Docu von Django über Signals nicht wirklich hilfreich war und andere Docs und Blogs im Web veraltet waren, hat mich das Wiki ein wenig verwirrt. Aber anhand des Wikis konnte man erahnen wie die Programmierer von Django es sich gedacht haben.

from django import dispatch

mail_senden = dispatch.Signal()

def send_mail(sender, user, adress, signal, *args, **kwargs):
    print "signal!!!"

mail_senden.connect(send_mail)

def test():
    mail_senden.send(sender=None, user="user", adress="mail@host.tld")

Ich denke der Quellcode ist recht selbstverständlich. “mail_senden” wird zum Signal. Dann wird send_mail definiert, welche aufgerufen wird, sobald ein Signal eingeht. dann wird das Signal an die Funktion gebunden (connect). In der Funktion test wird dann testweise einfach mal etwas über das Signal gesendet.

Zusammengesucht habe ich diese Infos unter den Webseiten:
mercurytide
b-list.org
Django Wiki
chrisdpratt.com

Lange hat es gedauert aber ich hab es mit tausenden von Codefetzen geschafft. Daten die im 1. Formular eingegeben wurden, im 2. Formular zu benutzen. Das Problem bei mir war: Im 1. Formular wird das Land und die Postleitzahl eingegeben, im 2. Wizard-Schritt sollte die Stadt aus einer Dropdown Box ausgewählt werden.

Leider sehen die Djangoentwickler keinen Sinn darin, eine Funktion mitzugeben die es ermöglicht, die Daten aus vorherigen Formularen abzufragen. Also musste ich mich dieses wirklich Dirty-Hacks bedienen:

class NeuerBenutzerWizard(FormWizard):
    def process_step(self, request, form, step):
        if step==0 and form.is_valid():
            self.__f0_cleaned_data=form.cleaned_data

    def get_form(self, step, data=None):
        form = super(NeuerBenutzerWizard,self).get_form(step=step,data=data)
        if step == 1:
            from models import Locations
            form.fields['ort'].queryset=Locations.objects.filter(
                        land=self.__f0_cleaned_data['land'],
                        plz=self.__f0_cleaned_data['postleitzahl']).all()
        return form

    def done(self, request, form_list):
        return render_to_response('done.html', {
            'form_data': [form.cleaned_data for form in form_list],
        })

Mit der Funktion process_step (Zeile: 2) habe ich nachgesehen ob der Schritt 1 (Der Zähler startet bei 0, daher steht dort 0. Zeile: 3) erfolgreich war und das Formular valid ist. Dann habe ich die Daten aus dem Formular No. 1 mit form.cleanded_data in self.__f0_cleaned_data gespeichert (Zeile: 4).

Mit der Funktion get_form (Zeile: 6) bekommt man immer das geladene Formular vorgesetzt bevor es angezeigt wird. Dort habe ich abgefragt, ob das Formular zu Schritt 2 (Zeile: gehört. Nun konnte ich über self.__f0_cleaned_data['land'] (Zeile: 11 & 12) auf die im 1. Formular gemachten Landangaben zugreifen. 

Allem in allem, ein wirklich übler Hack und ich hoffe die Djangoentwickler arbeiten da noch einen besseren Weg aus.

Lange Zeit war ich mit nGinx zufrieden, ich muss sagen ein wirklich toller Webserver – vor allem schnell. Was mir nur in letzter Zeit ein wenig auf den Geist ging, waren die RegEXP die ich für das Rewrite verwenden musste. Auch das fCGI Gedöns gefiel mir nicht wirklich mehr. Zumal man alles in die Startscripte werfen musste. Vor allem wenn man viele Django Projekte hat, wird das schnell unübersichtlich.

Durch Zufall bin ich auf den Cherokee Webserver gestoßen – wo die Webseite mir förmlich durch die Leitung entgegen sprang. Dick oben prangerte “The Fastest free Web Server out there!“. Ich musste schmunzeln – das behauptet ja jeder von sich. Also hab ich kurzer Hand auf dem Server den Cherokee installiert. Dem nGinx und Cherokee habe ich die selbe HTML Datei zum futtern gegeben und das Ergebnis war doch überraschend.

Naja dachte ich mir – schauen wir uns das doch mal hier beim Blog an – und tatsächlich – Cherokee interagiert wesentlich besser mit php (es wird php-cgi verwendet) als per nGinx und fCGI.

Ich werde das ganze mal im Auge behalten wie sich die Performance auf den Server auswirkt. Was ich außerdem Loben musst ist das “Admin Interface”. Endlich keine stupide Terminalarbeit mehr sondern mal was einigermaßen vernünftiges obgleich auch sehr flexibel Webinterface.

Cherokee is a very fast, flexible and easy to configure Web Server. It supports the widespread technologies nowadays: FastCGI, SCGI, PHP, CGI, SSI, TLS and SSL encrypted connections, Virtual hosts, Authentication, on the fly encoding, Load Balancing, Apache compatible log files, Data Base Balancing, Reverse HTTP Proxy, Traffic Shaper, Video Streaming and much more.

Ich werde einiges davon sicherlich verwenden und weiter berichten.

Wo ich auch lobende Worte los werden muss, ist bei der Dokumentation – strikt in Englisch aber dennoch reichlich Beispiele für alle wichtigen Anwendungen: WordPress, Django usw. usf.
ps: Auch Angelplatz.com, welches auf Django baiert, habe ich auf den Cherokee umgestellt – mit erheblich verbesserter Ladezeit!