Wangoo

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:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

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!

Nun warum sollte man zwei Interessengruppen bzw. Hobbys nicht vereinen? Ich mag das Angeln aber ich beschäftige mich vor dem heimischen PC ähm iMac auch gern mit Django und Python. Nachdem ich reichlich Besucher auf meinen Blogeintrag “Forellenteiche in Deutschland” bekommen habe, habe ich mir überlegt eine gescheite Übersicht mit Suchfunktion usw zu erstellen.

Nach langer Domainnamensuche habe ich mich für Angelplatz.com entschieden. Die Webseite ist noch im Aufbau und nur ca. 100 Teiche in Deutschland sind eingepflegt. Geplant sind folgende features:

• Suchfunktion
• Google Map Übersicht
• Mehrsprachigkeit
• Bewertung der Teiche mit Punkten
• Kommentare
• Fangbilder
• Europaweite Sammlung von Angelplätzen
• Einblendung von Werbebannern der Fischerbetriebe

Eine erste Vorversion habe ich zu Demozwecken installiert: www.angelplatz.com

Über Kommentare würde ich mich sehr freuen.

Erstellt wurde die Seite mit Django und Python – als Frontend für statische Seiten dient nGinx.

Ich wollte bei meinem Djangoprojekt die Maps von Google verwenden und bin auf geopy gestoßen. Super dachte ich mir, eine API die sehr einfach zu verwenden ist. Eingebaut … getestet -> FEHLER: UnicodeEncodeError

Super! Ich mir den zu suchenden String angesehen – ja ein ß drinne – hmm das sollte eigentlich bei Unicode kein Thema sein aber leider wird das ganze durch urlencode() geschickt und da wird das Exception ausgeworfen.

Nach mehreren Stunden, zwei Kannen Kaffee und einem Blutdruck der meinem Reifendruck gleich kommt – entdeck ich durch Zufall die Lösung meines Problems:

STRING.encode(‘ascii’, ‘xmlcharrefreplace’)

Lustigerweise hab ich anstatt “xmlcharrefreplace” immer, wie fast überall empfohlen, nur das replace benutzt. Das hat dann aus “Borstenbachstraße” enfach mal “Borstenbachstra?e” gemacht und google-maps hat dann da “Breitenbachstraße” draus gemacht.

Die Lösung hab ich im Wiki von Python.org gefunden.

Lange hab ich nach einer IDE für Python gesucht, viele Geeks und Nerds benutzen Vi(m) oder gEdit sowie Notepad(++). Nach langem suchen hab ich die Komodo IDE (kostenpflichtig) gefunden. Die abgespeckte Version Komodo Edit ist kostenlos.

Beide Programme sind vom Look & Feel wirklich gut. Leider haperts aber schon bei der Autovervollständigung der sog. “Code Completition“. Die Grundpakete von Python werden mehr oder minder schon angezeigt aber für Extrapakete á la Django schon garnicht mehr. Auch wenn man ein Paket per Alias (import datetime as newdatetime) umbenennt klappt es gar nicht mehr mit der Vervollständigung.

Vorgestern ist mir dann “EasyEclipse for Python” in die Hand gefallen. Eclipse kannte ich schon vom Java-Programmieren her und fand ich damals schon ganz gut neben Netbeans. Doch auch hier – selbiges Problem mit dem Alias beim Import. Außerdem musste erst noch ein Plugin installiert werden um überhaupt HTML Dateien öffnen zu können. Es gab leider kein Plugin für den Django Template Syntax.

Heute ist mir durch einen Blogeintrag UliPad nahegelegt worden.

Funktionen:
* syntax highlighting specially for Django templates
* auto-completion
* folding
* zoom-in or zoom-out editor window
* lightweight on memory
* cross-platform
* code snippets
* directory browser (sort of project browser)
* multi-view support

Also UliPad kann ich nur als Python Editor empfehlen.