Die selbst geiselung mit "Framework" Software

Die selbst geiselung mit "Framework" Software
12.05.2010 19:44
  1. Es gibt fertige Software. Entweder Sie gefällt einem, oder man lässt Sie bleiben.
  2. Es gibt C, Python, Perl, PHP, Java u.v.m. Mit denen kann man sich die Software seiner Träume schreiben... theoretisch. Meist geht einem die Zeit dafür aus.
  3. Es gibt "Frameworks", diese sind der passend Rahmen für dein Kunstwerk. Aber nur wenn man den Rahmen findet, der am besten passen könnte.

Ich verwende aktuell Django für einige Projekte an denen ich arbeite. Es erleichtert mir unglaublich viel, damit die Seite meines Vereins zum geheimen Projekt Management Tool mit öffentlichen Inhalten für die Besucher wird. Eines von Djangos Prinzipien ist die strikte Einhaltung der Model-Template-View Anekdote (fast das gleiche wie Model-View-Controller). Diese sorgt für den Auslöser meines Problems: Ein Model kann von selbst nicht wissen wer es jetzt verändert hat. Wenn ich also ein "Aufgabe" Objekt habe, und ich will mit abspeichern wer die Aufgabe erstellt hat, muss ich mich schon selber darum kümmern den Ersteller mit zuschicken.

Diese Aufgabe ist leicht zu umschiffen. In der Ansicht, mit der ich die Aufgabe verändern/erstellen kann ist der Bearbteiter bekannt. Ich kann also den Bearbeiter im Quelltext setzen, bevor ich das Model in der Datenbank speichern lasse.

Nächste Hürde: Ich wollte ein Logbuch über die Änderungen die eine Aufgabe erfahren hat erstellen. Am Ende habe ich keine bessere Lösung gefunden als die save() Methode des Django-Formular zu überschreiben. Jedes mal wenn ich über dieser Formular eine Aufgabe ändere, wird ein Logeintrag erstellt, und die Änderungen an die Verantwortlichen per Mail geschickt.

Halb-Fertig macht mich ganz Fertig...

Ich wollte jetzt aber mehrere Aufgaben gleichzeitig zum bearbeiten in einer Ansicht darstellen. Auch dafür hat Django was passendes die FormSets! Mit ihrer Hilfe kann man mehrere Formulare zu einem Formular zusammenfassen. Alle Formulare kann man Zeitgleich auf Ihre Richtigkeit überprüfen, alle Änderungen der Formulare kann man mit einem save() Aufruf abspeichern, u.v.m.

Aber ich kann nicht so einfach den Ticket-Bearbeiter bei allen Unter-Formularen eines FormSets festlegen. Die Dokumentation empfiehlt dafür folgenden Code:

instances = formset.save(commit=False)
    for instance in instances:
        # do something with instance
        instance.save()

In der ersten Zeile bekommen ich "Model" Instanzen aller veränderten Formulare zurück, welche ich dann der Reihe nach weiter bearbeiten und speichern kann. Bei mir führt das aber nicht zum gewünschten Ergebnis, denn ich will ja das sich mein Formular um das speichern kümmert, und nicht das Model direkt gespeichert wird. Sonst werden keine Log-Einträge erstellt, und keine Mails verschickt.

Die Django Dokumentation konnte mir nicht mehr weiter helfen. Auch Google hatte keine Lösung parat. Im Endeffekt habe ich mir den Code der Formsets angesehen und doch noch ein Lösung ausgegraben:

for form in formset.forms:
    if form.has_changed and form.is_valid:
        # do something with the form
        form.save()

Fazit:

  • Ein halb fertiges System wie Django kann einem wirklich viel Arbeit abnehmen, aber nicht das Denken.
  • Die halbe Software muss so gut zu den Entwicklern passen wie die fertige zu den Anwendern. Sie frisst Entwicklungszeit, aber nicht so viel wie eine komplette Eigenproduktion. Die Frameworks kombinieren damit die Stärken und Schwächen aus beiden Extremen.
  • Hätte ich die Seite von Grund auf selbst geschrieben, dann hätte ich dieses Problem wohl nicht gehabt. Ich wäre vermutlich noch nicht einmal bei dem Punkt angekommen wo ich mir um solche Usability-Spielereien Sorgen gemacht hätte.
  • Ich bin Froh das Django "Open-Source" ist, ohne einen Blick in den Quelltext hätte ich keine Lösung für mein Problem gefunden.

Kommentare
danke
ckpinguin (unangemeldet), Mittwoch, 19. Mai 2010 09:56:55
Ein/Ausklappen

Danke für den Beitrag, denn die ewige Lobhudelei von Django, Rails und co. nervt total, denn beide sind noch lange nicht so einfach, wie es immer heisst. Man kann tolle Dinge damit machen in kurzer Zeit, aber es braucht trotzdem sehr tiefes Produktewissen und das Deployment kann zur Hölle werden (Ruby-Mongrel-wasweissich).



Bewertung: 55 Punkte bei 2 Stimmen.
Den Beitrag bewerten: Gut / Schlecht

Infos zum Autor