Warum existiert dieses Projekt?

Django ist aus einem sehr praktischen Bedürfnis entstanden: World Online, ein Verlag für Online-Publikationen, ist verantwortlich für das Entwickeln von Webanwendungen für Journalisten mit Deadlines. In der hektischen Redaktion hat World Online oft nur einige Stunden Zeit, eine Webanwendung vom Konzept bis zur Veröffentlichung zu entwickeln.

Gleichzeitig waren die World Online Webentwickler konstant perfektionistisch wenn es darum ging, den besten Gewohnheiten von Webentwicklung zu folgen.

Gegen Ende 2003 wurden die World Online Entwickler (Adrian Holovaty und Simon Willison) PHP los und fingen an, Python zum Entwickeln ihrer Websites zu nutzen. Da sie sehr komplizierte, interaktive Seiten wie Lawrence.com erstellten, begannen sie, ein allgemeines Framework für Web-Entwicklung zu erstellen, das ihnen erlaubt, Webanwendungen schneller zu entwickeln, verbesserten es über zwei Jahre ständig und fügten Neuerungen hinzu.

Im Sommer 2005 hatte sich World Online entschieden, die resultierende Software, Django, unter einer Open source Lizenz zu veröffentlichen. Django wäre ohne eine Menge anderer Open Source Projekte — Apache, Python, und PostgreSQL um nur einige zu nennen — nicht möglich und wir freuen uns riesig, der Open Source Community etwas zurückgeben zu können.

Was bedeutet “Django”, und wie spricht man es aus?

Django ist nach Django Reinhardt benannt, ein Jazz-Gitarrist, der von den ‘30ern bis zu den frühen ‘50ern wirkte und bis heute als einer der besten Gitarristen angesehen wird.

Hör dir seine Musik an. Du wirst sie mögen.

Django [dʒãŋgo] wird SCHÄNG-oh ausgesprochen, am Anfang also wie “Gin” oder “Joy”. Das “D” ist stumm.

Wir haben außerdem eine Audiodatei von der Ausprache aufgenommen.

Ist Django stabil?

Ja. World Online nutzt Django seit mehr als drei Jahren. Seiten, die mit Django erstellt wurden, haben über einer Millionen Zugriffe pro Stunde und einige Slashdottings hinter sich. Ja, es ist sehr stabil.

Skaliert Django?

Ja. Da verglichen mit Entwicklungszeit Hardware billig ist, wurde Django so entworfen, dass es so viele Vorteile der Hardware nutzt, wie möglich.

Django nutzt eine “shared-nothing” Architektur. Das heißt: Du kannst überall Hardware hinzufügen — Datenbankserver, Cache-Server oder Web-/Anwendungsserver.

Das Framework hat die einzelnen Komponenten strikt getrennt, wie ihren Datenbankabschnitt und Anwendungsabschnitt. Und es hat ein simples, aber leistungsstarkes Cache-Framework.

Wer steckt dahinter?

Django wurde bei World Online entwickelt, die Webabteilung einer Zeitung aus Lawrence, Kansas, USA.

Adrian Holovaty

Adrian ist ein Webentwickler mit Journalismus-Erfahrung. Er war für 2.5 Jahre Hauptentwickler bei World Online, in denen Django entwickelt und in den World Online Seiten implementiert wurde. Jetzt arbeitet er für washingtonpost.com, wo er Datenbank-basierte Informationsseiten erstellt und betreut immer noch das Django-Projekt. Er spielt gerne Gitarre (Django Reinhardt Style) und machte Nebenprojekte wie chicagocrime.org. Er lebt in Chicago.

Im IRC heißt Adrian adrian_h.

Jacob Kaplan-Moss

Jacob ist ein Klugscheißer aus Kalifornien, der genauso viel Zeit mit Coden verbringt wie mit Kochen. Er ist Hauptentwickler bei World Online und bastelt aktiv an einigen Nebenprojekten. Er hat an den Python-ObjC Bindings mitgearbeitet und war der Erste, der herausgefunden hat wie man Tivo Anwendungen in Python schreibt. Zuletzt hat er sich mit Python auf der PSP die Zeit vertrieben. Er lebt in Lawrence, Kansas.

Im IRC heißt Jacob jacobkm.

Simon Willison

Simon ist ein respektierter Webentwickler aus England. Er hatte ein einjähriges Praktikum bei World Online, in dem Adrian und er Django von Grund auf entwickelt haben. Er ist der enthusiastischste Brite, den du je treffen wirst, er ist leidenschaftlich über das Vorgehen in Webentwicklung und hat über Jahre ein gutgelesenes Weblog über Webentwicklung auf http://simon.incutio.com/ betrieben. Er arbeitet für Yahoo UK, wo er den Titel “Hacker Liason” erhalten hat. Er lebt in London.

Im IRC heißt Simon SimonW.

Wilson Miner

Wilson’s Design Fähigkeiten lassen uns alle nach Rockstars aussehen. Momentan arbeitet er als Interactive Designer bei Apple. Frag ihn nicht woran er arbeitet oder er wird dich töten. Er lebt in San Francisco.

Im IRC heißt Wilson wilsonian.

Welche Seiten nutzen Django?

Das Django-Wiki beinhaltet eine konstant wachsende Liste mit Seiten, die Django nutzen. Du kannst auch einfach deine Seite zur Liste hinzuzufügen, wenn sie Django nutzt.

Django scheint ein MVC-Framework zu sein, aber ihr nennt den Controller “view” und den View “template”. Wieso nutzt ihr nicht die Standardnamen?

Nun ja, die Standardnahmen sind diskussionsbedürftig.

In unserer Interpretation von MVC beschreibt der “View” die Daten die dem Benutzer präsentiert werden. Es ist nicht notwendigerweise wie die Daten aussehen, sondern welche Daten präsentiert werden. Der View beschreibt welche Daten du siehst, nicht wie du die Daten siehst. Das ist der kleine Unterschied.

Also ist aus unserer Sicht ein “View” die Python-Callback-Funktion für eine bestimmte URL, da diese Callback-Funktion beschreibt, welche Daten präsentiert werden.

Außerdem ist es vernünftig, den Inhalt von der Präsentation zu trennen — hier kommen Templates ins Spiel. In Django beschreibt ein “View” welche Daten präsentiert werden, aber ein View benutzt normalerweise ein Template, welches beschreibt wie die Daten präsentiert werden.

Wo ist denn dann der “Controller”? In Djangos Fall ist es wahrscheinlich das Framework selber: Das Gerüst, das einen Request gemäß der Django URL-Konfiguration zum dazugehörigen View sendet.

Wenn du akronymhungrig bist, kannst du sagen, dass Django ein “MTV”-Framework ist — das steht für “model”, “template”, und “view”. Diese Aufteilung macht wesentlich mehr Sinn.

Letzten Endes kommt es natürlich darauf an, mit der Arbeit fertig zu werden. Und egal wie das alles benannt ist, mit Django können wir unsere Aufgaben so erledigen, wie es uns am logischsten erscheint.

<Framework X> macht <feature Y> — warum nicht Django?

Wir sind uns bewusst, dass es andere tolle Web-Frameworks gibt und wir sind auch nicht abgeneigt, durch sie inspiriert zu werden. Aber Django wurde genau deswegen entwickelt, weil wir mit dem aktuellen Stand unglücklich waren. Also sei dir bitte bewusst, dass es für uns kein Grund ist, ein Feature zu Django hinzuzufügen, nur “weil <Framework X>” es hat.

Warum habt ihr Django von Grund auf geschrieben anstatt andere Python Module zu nutzen?

Als Django vor einigen Jahren ursprünglich geschrieben wurde, haben Adrian und Simon recht viel Zeit damit verbracht, die verschiedenen Python Web-Frameworks zu erforschen.

Unserer Meinung nach war keines von ihnen ganz auf der Höhe.

Wir sind pingelig. Du kannst uns sogar Perfektionisten nennen. (Mit Deadlines.)

Mit der Zeit sind wir über Open Source Bibliotheken gestolpert, die Dinge machten, die wir bereits implementiert hatten. Es beruhigte uns, dass andere Leute unsere Probleme ähnlich gelöst hatten, aber es war zu spät, anderen Code zu integrieren: Wir hatten schon unsere eigenen Module in verschiedenen Produktionseinstellungen geschrieben, getestet und implementiert — und unser Code hatte unsere Bedürfnisse gut erfüllt.

Wir fanden allerdings, dass die existierenden Frameworks/Tools in den meisten Fällen fundamentale, fatale Fehler machten, wodurch wir penibel wurden. Kein Modul erfüllte unsere Philosophie zu 100%.

Wie gesagt: Wir sind wählerisch.

Wir haben unsere Philosophien auf der Design Philosophie Seite dokumentiert.

Habt ihr einen von diesen schicken “Screencasts”?

Darauf kannst du Gift nehmen, dass wir bald welche haben. Aber da wir immer noch an einigen Punkten arbeiten, gehen wir lieber auf Nummer sicher, damit sie den Endzustand von Django 1.0 und kein Zwischending darstellen. Mit anderen Worten: Wir wollen nicht viel Arbeit mit dem Erstellen von Screencasts verbringen, weil sich Djangos APIs noch ändern wird.

Ist Django ein Content-Management-System (CMS)?

Nein, Django ist kein CMS oder irgendeine Sorte von “Fertigprodukten”. Es ist ein Web-Framework, ein Programmierwerkzeug, das dir ermöglicht, Webseiten zu erstellen.

Zum Beispiel macht es nicht viel Sinn, Django mit so etwas wie Drupal zu vergleichen, da Django etwas ist, womit man Sachen wie Drupal zu erstellen kann.

Natürlich ist Djangos Administrationsoberfläche fantastisch und zeitsparend — aber die Administrationsoberfläche ist ein Modul von Django, dem Framework. Außerdem heißt das nicht, dass es, obwohl Django spezielle Behelfsfunktionen zum Erstellen von “CMS-artigen” Anwendungen hat, für das Erstellen “keiner-CMS-artigen” Anwendungen ungeeignet ist (Was immer das bedeutet!).

Wann werdet ihr Django 1.0 veröffentlichen?

Kurze Antwort: Wenn wir uns mit Djangos APIs wohlfühlen, alle Funktionen hinzugefügt haben, die wir für den “1.0”-Status für notwendig halten und rückwärtskompatibel sind.

Die Integration von Djangos magic-removal Branch war ein großer Schritt in Richtung 1.0.

Natürlich solltest du beachten, dass recht viele Seiten das aktuelle Django nutzen. Lass dich nicht von der fehlenden 1.0 Veröffentlichung abtörnen.

Wie kann ich die Django-Dokumentation herunterladen, um sie offline zu lesen?

Die Django-Dokumentation ist im docs Verzeichnis jedes Django Tarball Releases zu finden. Die Dokumentation ist im ReST (ReStructured Text) Format geschrieben und jede Textdatei ist für eine Webseite auf der offiziellen Django-Seite verantwortlich.

Weil die Dokumentation in einer Revisionskontrolle liegt kannst du die Dokumentationsänderungen einsehen wie du die Codeänderungen einsehen kannst.

Technisch gesehen, wird die Dokumentation aus den ReST Dokumenten der letzten Entwicklerversionen generiert. Also wird die Dokumentation auf der Django-Seite mehr Informationen als die Dokumentation, die mit dem letzten Django-Release kommt, preisgeben.

Wo kann ich Django-Entwickler zum Engagieren finden?

Besuche unsere Entwickler zum Engagieren-Seite, wo eine Liste ist mit Leuten, die froh sind, wenn sie dir helfen können.

Du kannst außerdem einen Job auf http://www.gypsyjobs.com/ posten.

Wie fange ich an?

1. Lade den Code herunter.
2. Installiere Django (lies die Installationsanleitung).
3. Gehe durch das Tutorial.
4. Schau durch den Rest der Dokumentation und stelle Fragen wenn du in Schwierigkeiten kommst.

Wie behebe ich die “install a later version of setuptools” Fehlermeldung?

Führe einfach das ez_setup.py Skript im Django-Verzeichnis aus.

Was sind Djangos Abhängigkeiten?

Django benötigt Python 2.3 oder neuer. Keine anderen Python Bibliotheken werden für das normale Benutzen von Django benötigt.

Für eine Entwicklungsumgebung — wenn man mit Django experimentieren will — braucht man keinen separaten Webserver. Django hat seinen eigenen kleinen Entwicklungsserver. Für eine Produktionsumgebung empfehlen wir Apache 2 und mod_python, obwohl Django der WSGI Spezifikation folgt, was heißt, dass es auf einer Vielzahl von Serverplattformen läuft.

Wenn du Django mit einer Datenbank nutzen willst, was wahrscheinlich der Fall ist, brauchst du eine Datenbank. Wir empfehlen PostgreSQL, da wir einfach PostgreSQL-Fans sind. Außerdem werden MySQL, SQLite 3 und Oracle unterstützt.

Hab ich irgendeinen Nachteil, wenn ich anstatt Python 2.3 eine neuere Python Versionen nutze, wie Python 2.5?

Nein. Django läuft garantiert mit allen Python Versionen von 2.3 und höher.

Wenn du eine neuere Python Version als 2.3 verwenden willst, kannst du dadurch natürlich Vorteile von neuen Features in Python nutzen — zusammen mit den Geschwindigkeitsverbesserungen und anderen Optimierungen, die an der Python vorgenommen wurden. Django sollte allerdings gleich gut mit 2.3, 2.4 oder 2.5 arbeiten.

Muss ich mod_python nutzen?

Obwohl wir mod_python für Produktionszwecke empfehlen, musst du es nicht nutzen. Dank der Tatsache, dass Django einen Standard namens WSGI nutzt. Django kann zu jedem WSGI-fähigem Server sprechen. Andere nicht-mod_python Umgebungen sind FastCGI, SCGI oder AJP. Siehe Wie man Django mit FastCGI, SCGI oder AJP nutzt für mehr Informationen.

Schaue auch auf die Wikiseite zu Server-Konfigurationen für weitere Informationen.

Wenn du einfach nur herumspielen willst und nur mit deinem lokalen Computer entwickeln willst, kannst du den Entwicklungs-Webserver nutzen, der in Django enthalten ist. Das funktionieren sofort.

Wie installiere ich mod_python auf Windows?

• Für Python 2.4, hole dir mod_python von win32 build of mod_python for Python 2.4
• Für Python 2.4, schaue dir das Django on Windows howto an.
• Für Python 2.3, hole dir mod_python von http://www.modpython.org/ und lese Running mod_python on Apache on Windows2000.
• Probiere außerdem (nicht Windows-spezifisch) diesen Guide um mod_python ans Laufen zu bekommen.

Läuft Django bei SharedHosting-Anbietern (wie TextDrive oder Dreamhost)?

Siehe unsere Django-freundliche Webhoster-Seite.

Soll ich die offizielle Version oder die Entwicklerversion nutzen?

Die Django-Entwickler verbessern Django täglich und checken sehr selten nicht lauffähigen Code ein. Wir nutzen den Entwicklungscode (aus dem Subversion Repository) direkt auf unseren Servern, wir sehen es also als stabil an. Deswegen empfehlen wir, dass man den aktuellsten Entwicklungscode nutzt, weil er normalerweise mehr Funktionen und weniger Fehler als die “offiziellen” Releases enthält.

Warum bekomme ich einen Error wenn ich DJANGO_SETTINGS_MODULE importiere?

Stelle sicher, dass:

• die Umgebungsvariable DJANGO_SETTINGS_MODULE auf ein richtiges Python Modul gesetzt ist(z.B. “mysite.settings”).

• Das Modul in sys.path ist. (import mysite.settings sollte funktionieren.)

• Das Modul (natürlich) keine Syntaxfehler enthält.

• Wenn du mod_python nutzt, aber nicht Djangos Request Handler, musst du einen mod_python Bug umgehen bezüglich der Nutzung von SetENV. Bevor du irgendetwas von Django importierst musst du folgendes machen:

  os.environ.update(req.subprocess_env)
  

(wobei req das mod_python Requestobjekt ist.)

Ich kann eure Templatesprache nicht verstehen. Muss ich sie nutzen?

Wir glauben, dass unsere Template Engine das Beste seit der Erfindung der Schokolade ist, verstehen aber auch, dass das Wählen einer Template Sprache einer Religion nahe kommt. Es gibt nichts in Django, dass dich dazu zwingt, die Template Engine zu benutzen. Wenn du also ein Anhänger von ZPT, Cheetah oder was auch immer bist, kannst du diese auch nutzen.

Muss ich eurer Datenmodel/Datenbanklayer nutzen?

Nein. Wie das Template System sind Datenmodel und Datenbanklayer vom restlichen Framework unabhängig.

Wie nutze ich Bilder- und Dateifelder?

Ein FileField oder ein ImageField in einem Model benötigt einige Schritte:

1. Setze MEDIA_ROOT in deiner Einstellungsdatei auf einen vollständigen Pfad, wo die hochgeladenen Dateien von Django gespeichert werden. (Aus Performancegründen werden diese Dateien nicht in der Datenbank gespeichert.) Setze MEDIA_URL auf den Basispfad der öffentlichen URL dieses Verzeichnisses. Stelle sicher, dass das Verzeichnis für den Webserver-Benutzer beschreibbar ist.
2. Füge das FileField oder das ImageField zu deinem Datenmodell hinzu und versichere dich, dass du die upload_to-Option gesetzt hast, um Django zu sagen, in welches Unterverzeichnis von MEDIA_ROOT die Dateien hochgeladen werden sollen.
3. All das wird in deiner Datenbank in Form eines Pfades zu der Datei (relativ zu MEDIA_ROOT) gespeichert. Du wirst wahrscheinlich die komfortable get_<fieldname>_url-Funktion Djangos nutzen. Beispielsweise wenn dein ImageField mug_shot heißt, bekommst du die absolute URL zu deinem Bild in einem Template mit {{ object.get_mug_shot_url }}.

Wie kann ich die rohen SQL-Queries sehen, die Django ausführt?

Prüfe, dass deine Django-DEBUG Einstellung auf True gesetzt ist. Dann mache einfach folgendes:

>>> from django.db import connection
>>> connection.queries
[{'sql': 'SELECT polls_polls.id,polls_polls.question,polls_polls.pub_date
FROM polls_polls', 'time': '0.002'}]

connection.queries ist nur vorhanden wenn DEBUG auf True steht. Es ist eine Liste von Dictionaries in der Reihenfolge der Queryausführung. Jedes Dictionary hat folgendes:

``sql`` -- Das rohe SQL-Statement
``time`` -- Wie lange die Statementausführung in Sekunden gedauert hat.

connetion.queries beinhaltet alle SQL-Statments — INSERTs, UPDATEs, SELECTs, etc. Jedes mal wenn du etwas mit der Datenbank machst, wird der Query aufgenommen.

Kann ich Django mit einer bereits bestehenden Datenbank nutzen?

Ja. Siehe Integration mit einer bereits bestehenden Datenbank.

Wenn ich Änderungen an meinen Models mache, wie aktualisiere ich dann die Datenbank?

Wenn es dir nichts aus macht, die Daten zu löschen: Dein Projekt-manage.py-Tool hat eine Option, das SQL für eine bestimmte Anwendung zurückzusetzen:

manage.py reset appname

Das löscht alle Tabellen, die zu appname gehören und erstellt sie neu.

Wenn du die Daten nicht löschen willst, musst du das ALTER TABLE-Statement manuell in deiner Datenbank ausführen. Das ist der Weg, wie wir es immer gemacht haben, weil das Behandeln von Daten ist eine sehr empfindliche Arbeit, die wir nicht automatisieren wollten. Nichtsdestotrotz wird gerade daran gearbeitet, halb-automatisierte Datenbank Aktualisierungen zu ermöglichen.

Unterstützen Djangos Datenmodelle mehrspaltige Primary Keys?

Nein. Lediglich einspaltige Primary Keys sind möglich.

Aber das ist kein Fehler in der Praxis, da dich nichts davon abhält, andere Bedingungen (mithilfe der unique_together Modeloption oder Erstellen der Bedingung direkt in deiner Datenbank) hinzuzufügen und die Einzigartigkeit auf diese Art durchzusetzen. Einspaltige Primary Keys werden für Dinge wie die Administrationsoberfläche gebraucht. Zum Beispiel brauchst du einen simplen Weg, ein Objekt zu erstellen, zu editieren oder zu löschen.

Wie kann ich eine Datenbank-spezifische Option zu meinen CREATE TABLE-Statements, wie MyISAM als Tabellentyp angeben?

Wir wollen Spezialfälle im Django-Code vermeiden, die allen Datenbank-spezifischen Optionen, wie Tabellentyp etc., entgegenkommen. Wenn du eine von diesen Optionen nutzen willst, kannst du du eine SQL-Startdatei erstellen, die ALTER TABLE-Statements enthält. Die Startdateien werden in deiner Datenbank nach den CREATE TABLE-Statements ausgeführt.

Wenn du zum Beispiel MySQL nutzt und willst, dass deine Tabellen den MyISAM Tabellentyp nutzen, musst du eine Startdatei mit folgendem Inhalt anlegen:

ALTER TABLE myapp_mytable ENGINE=MyISAM;

Wie in der SQL-Startdatei-Dokumentation beschrieben, kann diese SQL-Datei beliebiges SQL enthalten, also jede Art von Änderungen durchführen.

Warum belegt Django immer mehr Arbeitsspeicher?

Django macht dies normalerweise nicht. Wenn deine Django-Prozesse immer mehr Speicher grundlos belegen, solltest du kontrollieren, ob deine DEBUG-Einstellung auf True steht. Wenn DEBUG True ist, dann speichert Django eine Kopie jedes ausgeführten SQL-Statements.

(Die Queries sind in django.db.connection.queries gespeichert. Siehe Wie kann ich die rohen SQL-Queries sehen, die Django ausführt?.)

Um dieses Problem zu lösen, musst du DEBUG auf False setzen.

Wenn du die Queryliste irgendwann in deinen Funktionen manuell leeren willst, kannst du einfach reset_queries() aufrufen, wie hier:

from django import db
db.reset_queries()

Ich kann mich nicht einloggen. Wenn ich einen korrekten Benutzernamen und ein korrektes Passwort eingebe, kommt einfach wieder die Loginseite ohne Fehlermeldungen.

Das Login-Cookie wurde nicht richtig gesetzt, weil die Domain des von Django geschickten Cookies nicht dem mit deines Browser übereinstimmt. Probiere die folgenden zwei Lösungsmöglichkeiten:

• Setze die SESSION_COOKIE_DOMAIN-Einstellung in deiner Einstellungsdatei übereinstimmend mit deiner Domain. Wenn du beispielsweise mit deinem Browser auf “http://www.mysite.com/admin/” gehst, must du in deine “myproject.settings” SESSION_COOKIE_DOMAIN = 'www.mysite.com' schreiben.
• Manche Browser (Firefox?) mögen es nicht, Cookies von Domains zu akzeptieren, die keine Punkte haben. Wenn du die Administrationsoberfläche auf “localhost” oder einer anderen Domain, die keine Punkte hat, laufen lässt, versuche “localhost.localdomain” oder “127.0.0.1” und setze SESSION_COOKIE_DOMAIN richtig.

Ich kann mich nicht einloggen. Wenn ich einen korrekten Benutzernamen und ein korrektes Passwort eingebe, erscheint die Loginseite mit der Fehlermeldung “Please enter a correct username and password” bzw. “Bitte einen gültigen Benutzernamen und ein Passwort eingeben.”

Wenn du dir sicher bist, dass dein Benutzername und dein Passwort korrekt sind, prüfe nach, ob in deinem Benutzerkonto is_active und is_staff auf True stehen hat. Die Administrationsoberfläche gibt nur denjenigen Benutzern Zugriff, die diese beiden Felder auf True gesetzt haben.

Wie kann ich die Cache-Middleware daran hindern, die Administrationsoberfläche zwischenzuspeichern?

Setze die CACHE_MIDDLEWARE_ANONYMOUS_ONLY Einstellung auf True. Schau dir auch die Cache Dokumentation für mehr Informationen an.

Wie kann ich auf der Administrationsoberfläche ein Feld auf den Benutzer setzen, der das dazugehörige Objekt bearbeitet hat?

Dafür bringt Django keine offiziellen Lösung mit. Aber da sehr oft nach diesem Feature gefragt wird, diskutieren wir gerade, ob und wie wir es implementieren können. Das Problem ist, dass wir die Datenmodelle nicht mit dem Admin verbinden wollen (womit man den aktuellen Benutzer ermitteln könnte). Es ist eben ein verzwicktes Problem.

Allerdings hat jemand eine Lösung gefunden, ohne Django patchen zu müssen, aber beachte bitte, dass das eine inoffizielle Lösung ist und es gibt keine Garantie, dass dies immer funktionieren wird.

Wie kann ich den Zugriff auf die Administrationsoberfläche einschränken, so dass Objekte nur von dem Benutzer editiert werden können, der es erstellt hat?

Siehe die Antworten zu den vorherigen Fragen.

Mein CSS und die Bilder für die Administrationsoberfläche funktionieren mit dem Entwicklungsserver einwandfrei, aber sie werden nicht beim Benutzen von mod_python angezeigt.

Siehe Admin Dateien bereitstellen in der Dokumentation zu mod_python

Mein “list_filter” enthält ein ManyToManyField, aber der Filter zeigt es nicht.

Django zeigt die Filter für ein ManyToManyField Feld nicht an, wenn es weniger als zwei zusammenhängende Objekte sind.

Wenn beispielsweise dein list_filter sites beinhaltet, aber nur eine Seite in deiner Datenbank ist, wird kein “Site”-Filter dargestellt, da in diesem Fall das Filtern bedeutungslos wird.

Wie kann ich die Funktionalität der Administrationsoberfläche verändern?

Du hast verschiedene Optionen. Wenn du ein Hinzufügen-/Ändern-Formular manipulieren willst, die Django automatisch generiert, kannst du beliebige Javascript-Module an die Seite anhängen, indem du in der class Admin js-Parameter setzt. Dieser Parameter ist eine Liste von URLs (als String), die auf Javascript-Module zeigen und mit dem <script>-Tag eingebunden werden.

Wenn du flexibler sein und nicht nur die automatisch generierten Formulare verbessern willst, kannst du auch eigene Admin Views entwickeln. Da die Administrationsoberfläche auch auf Django basiert, kannst du eigene Views schreiben, die auf das Authentifizierungssystem zugreifen, Zugriffsrechte überprüfen und alles machen was du willst.

Wenn du das Aussehen der Administrationsoberfläche verändern willst, lies die nächste Frage.

Die dynamische Administrationsoberfläche ist hässlich! Wie ändere ich das?

Wir finden die Administrationsoberfläche toll. Wenn du aber unsere Begeisterung nicht teilst, kannst du natürlich die Darstellung der Administrationsoberfläche ändern, indem du das CSS und/oder die dazugehörigen Bilder veränderst. Die Seiten bestehen aus semantischem HTML und bieten vielen Möglichkeiten, die CSS-Daten zu verändern. Für mehr Informationen gibt es eine gute Anleitung zum CSS auf der Administrationsoberfläche.

Wie erstelle ich Benutzer, ohne ihren Passwort-Hash editieren müssen?

Wenn du die Administrationsoberfläche dazu nutzen willst, Benutzer zu erstellen, musst du Django zur Entwicklerversion aktualisieren, in der das Problem am 4. August 2006 behoben wurde.

Du kannst außerdem die Python API nutzen. Siehe Benutzer erstellen für mehr Informationen.

Wie kann ich an Django mitarbeiten?

Danke für die Anfrage! Wir haben dieser Frage ein komplettes Dokument gewidmet. Es heißt An Django mitarbeiten.

Ich habe vor einigen Wochen eine Fehlerlösung im Ticketsystem eingereicht. Warum ignoriert ihr meinen Patch?

Keine Bange: Wir ignorieren dich nicht!

Es ist wichtig zu verstehen, dass es ein Unterschied zwischen “ein Ticket wird ignoriert” und “um ein Ticket wurde sich nicht gekümmert” gibt. Djangos Ticketsystem beinhaltet hunderte von offenen Tickets, mit verschiedenen Auswirkungen auf die Funktionalität für den Endbenutzer. Djangos Entwickler müssen alle Tickets prüfen und mit einer Priorität versehen.

Auch wenn deine Anfrage für eine neue Funktion keine Chance auf Integration in Django hat, werden wir sie nicht ignorieren — wir schliessen nur das Ticket. Wenn dein Ticket also immer noch offen ist, heißt es nicht, dass wir dich ignorieren, sondern dass wir keine Zeit hatten, es anzuschauen.