Wer hat diesen Fall noch nicht gehabt. Alle Inhalte einer Webseite sollen vom Netz genommen werden, die Redakteure und Administrationen der Seite sollen jedoch weiterhin Zugriff haben.

Das folgende Snippet hilft, eine Webseite mittels einer settings-Variable zu deaktivieren. Die Django-Verwaltung des Systems bleibt jedoch weiterhin erreichbar.

from django.shortcuts import render_to_response
from django.conf import settings

class MaintenanceMiddleware(object):    
    def process_view(self, request, view_func, view_args, view_kwargs):
        if getattr(settings, 'PAGE_IN_MAINTENANCE', False):
            view_name = '%s.%s' % (view_func.__module__, view_func.__name__)
            if view_name != 'django.contrib.admin.sites.root' \
            and view_name != 'django.views.static.serve' \
            and (not request.user.is_authenticated() or not request.user.is_staff):
                return render_to_response(getattr(settings, 'PAGE_MAINTENANCE_TEMPLATE', 'base_page_maintenance.html'))

Zur Verwendung:

• die Middleware Klasse irgendwo ablegen
• Middleware in die MIDDLEWARE_CLASSES (settings.py) eintragen

Konfiguration:

• PAGE_IN_MAINTENANCE auf True setzen, um die Webseite zu sperren
• PAGE_MAINTENANCE_TEMPLATE auf den Namen des Templates setzen, welches für die Maintenance-Seite verwendet werden soll

Ich arbeite derzeit an einem netten CMS Modul für Django, bei dem die einzelnen Seiten im Baukastenprinzip inkl. Drag+Drop zusammengesetzt werden. Beim Bearbeiten der einzelnen PageElements (die Blöcke, aus denen die Seite besteht) fiel mir auf, dass beim Speichern der REQUEST Parameter _popup nicht berücksichtigt wird, sondern stattdessen zur Change List des zu bearbeitenden Models gewechselt wird.

Dieses Stück Code schafft Abhilfe und schließt das Popup Window nach dem Speichern auf die gleiche Weise, wie beim Hinzufügen von Objekten bei z.b. ForeignKeys.

class ClosablePopupAdmin(admin.ModelAdmin):
    def response_change(self, request, obj):
        response = super(ClosablePopupAdmin, self).response_change(request, obj)
        if request.POST.has_key("_popup"):
            return HttpResponse('<script type="text/javascript">window.close();</script>')
        return response

Sehr simpel aber funktioniert ;-)

Ein kurzes Snippet zum Anzeigen der nächsten Geburtstage.
Dieser Codeausschnitt benötigt ein Profile Model mit einem birthday Feld (DateField oder DateTimeField) sowie einem ForeignKey auf django.contrib.auth.models.User mit dem Namen user.

Die Methode nimmt als Mengen-Parameter amount an, standardmäßig ist 5 gesetzt. Als Rückgabewert wird eine Liste mit den django.auth.models.User Objekten ausgegeben.

from myproject.accounts.models import Profile
import datetime

def next_birthdays(amount=5):
    birthdays = {}
    for profile in Profile.objects.select_related('user'):
        birthdays.setdefault((profile.birthday.month, profile.birthday.day), []).append(profile.user)
    dates = birthdays.keys()
    dates.sort()

    for i, date in enumerate(dates):
        if date >= (datetime.date.today().month, datetime.date.today().day):
            total = len(dates)
            first_pos = total - i
            break

    sorted_birthdays = dates[total - first_pos:]
    sorted_birthdays.extend(dates[:total - first_pos])

    output = []
    for date in sorted_birthdays:
        for user in birthdays[date]:
            output.append(user)
            if len(output) >= amount:
                return output
    return output

Es wird nur ein Datenbank Query abgefragt jedoch ist die Funktion relativ rechenintensiv. Ich empfehle hier unbedingt, die Ausgabe zu cachen.

Ich habe mir heute morgen einige Schema Evolution Tools für Django angesehen. django-evolution fällt aufgrund schlechter Erfahrung aus, dmigrations kommt nicht in Frage da nur MySQL unterstützt wird.

Bis jetzt mache ich meine Datenbank-Änderungen manuell mit einem Ordner voller sql Dateien, für jede Änderung eine Datei. Das klappt auch super, einziges Manko: man muss wissen, bei welcher "Version" man mit dem ausführen der sql Dateien beginnt.

Diesen Vorgang möchte ich nun automatisieren. Grundsätzlich muss erwähnt werden, das ich solch ein Tool nur für das Aktualisieren von Webseiten, die sich bereits im Produktionsbetrieb befinden, verwenden würde. Zum Zeitpunkt der Entwicklung ist die Erstellung der Änderungsscripte zu aufwändig.

Die Anwendung und Vorgehensweise stelle ich mir wie folgt vor:

Es existiert ein Model welches für jedes Model die aktuelle Version speichert:

class ModelVersion(models.Model):
    model = models.ForeignKey(ContentType, unique=True)
    version = models.PositiveIntegerField()

.. für in jeder Application existiert ein Python Modul "dbupdates" welches ein Dictionary CHANGES enthält:

CHANGES = {
    1, (
        'ATLER TABLE myapp_mymodel ADD COLUMN ...',
    ),
    2, (
        'ALTER TABLE myapp_mymodel DROP COLUMN ...',
        'DROP TABLE ...',
    ),
}

.. um Änderungen auszuführen, wird folgender Befehl ausgeführt:

alle Anwendungen aktualisieren:
./manage dbupdate

oder nur eine Anwendung aktualisieren:
./manage dbupdate [application]

Alternativ kann über den Parameter --startat=version die Startversion übergeben werden (ich merkte bereits an, das die Version zum Zeitpunkt des Checkouts bekannt sein muss, dannach wird die aktuelle Version in der Datenbank gespeichert.

Möglich ist auch, die CHANGES optional Datenbank-abhängig zu gestalten um auf eigenarten gewisser RDBMS einzugehen.

Soweit meine Idee, Feedback ist ausdrücklich erwünscht. Entweder als Kommentar, per Mail oder im IRC (#django-de / Freenode).

Nachtrag: Ich muss feststellen, dass ich hier bis auf wenige Kleinigekeiten dmigrations "nachbaue". Jedoch sehe ich derzeit keine andere Möglichkeit, da dmigrations ausschließlich mit MySQL arbeitet. Abgesehen davon wäre dmigrations jedoch genau das richtige für meine Anwendungszwecke.

Nachdem ich bereits längere Zeit nach einer Möglichkeit gesucht habe, den Inhalt von File-Feldern über Newforms-Admin löschen zu können, habe ich nun selbst ein kleines Widget geschrieben, welches genau das erledigt.

Neugeschrieben? Manch einer wird sich fragen, warum ich nicht eines der existierenden Snippets (#1, #2, es gibt sicher noch weitere) von djangosnippets.org nutze. Ganz einfach: sie machen eine Änderung des Models notwendig und genau das will ich nicht. Ich möchte meine Models nicht aufgrund eines Admin-Features ändern müssen.

Ich beginne erstmal mit dem Code selbst, Erläuterungen folgen:

from django.utils.safestring import mark_safe

class AdminDeleteFileWidget(admin.widgets.AdminFileWidget):
    def render(self, name, value, attrs=None):
        output = []
        output.append(super(AdminDeleteFileWidget, self).render(name, value, attrs))
        output.append('<br /><input type="checkbox" name="adfw_%s_delete" /> %s' % (name, 'Delete'))
        return mark_safe(u''.join(output))

class DeleteModelAdmin(admin.ModelAdmin):
    def response_change(self, request, obj):
        from django.db.models.fields.files import FileField
        for field in obj._meta.fields:
            if isinstance(field, FileField):
                if request.POST.has_key('adfw_%s_delete' % field.name):
                    try:
                        file = getattr(obj, field.name)
                        file.delete()
                    except:
                        pass

        return super(DeleteModelAdmin, self).response_change(request, obj)

    def formfield_for_dbfield(self, db_field, **kwargs):
        field = super(DeleteModelAdmin, self).formfield_for_dbfield(db_field, **kwargs)
        if field and isinstance(field.widget, admin.widgets.AdminFileWidget):
            field.widget = AdminDeleteFileWidget()
        return field

Der Aufbau ist relativ simpel. Ich habe die AdminFileWidget Klasse von Newforms-Admin beerbt und an die reguläre Ausgabe noch eine Checkbox zum Löschen angehängt. Der Name ist bewusst kompliziert gewählt, um zu vermeiden das ein normales Model-Feld überschrieben wird (adwf_feldname_delete).

Beim laden des Formulars wird für jedes Model-Feld die Methode formfield_for_dbfield aufgerufen. Diese Methode wird durch die DeleteModelAdmin Klasse überschrieben und prüft für jedes Feld, ob es sich um ein File-Feld handelt. Wenn ja, wird das Widget durch das AdminDeleteFileWidget ausgetauscht.

Beim Speichern des Formulars wird die Methode response_change aufgerufen. Hier prüft die Methode für jedes Model-Feld, ob es sich um ein File-Feld handelt und wenn dies zutrifft prüft die Methode weiter, ob das eine Datei hinterlegt ist. Ist das der Fall, wird das Vorhandensein der POST Variable adfw_feldname_delete abgefragt und bei erfolg die Datei gelöscht.

Um diese Funktionalität einsetzen zu können, müssen die Model-spezifischen Adminklassen von DeleteModelAdmin statt admin.ModelAdmin erben.