Projektdesign/FS-Layout für große Djangoprojekte

Question

Wie lässt sich ein großes Djangoprojekt am besten gestalten? Die Tutorials enthalten einfache Anweisungen zum Einrichten von Apps, Modellen und Ansichten, aber es gibt weniger Informationen darüber, wie Apps und Projekte aufgeteilt werden sollten und wie viel Teilen zwischen Apps in einem typischen Projekt zulässig/notwendig ist (offensichtlich hängt das stark davon ab) das Projekt) und wie/wo allgemeine Vorlagen aufbewahrt werden sollten.

Hat jemand Beispiele, Vorschläge und Erklärungen warum ein bestimmtes Projekt Layout besser ist als ein anderes? Ich interessiere mich besonders für die Integration einer großen Anzahl von Komponententests (2-5x die Größe der tatsächlichen Codebasis) und String-Externalisierung/Templates.

Answer 1

Die wichtigsten Richtlinien ähneln denen anderer großer Code-Projekte. Apps sollten eine eindeutige, klar definierte Verantwortung haben. Der Name "Anwendung" ist eine falsche Bezeichnung; Django-Apps sollten eher als wiederverwendbare Komponenten betrachtet werden, die zusammengesteckt werden können, um eine echte Anwendung zu erstellen. Tests für jede App sollten in dieser App enthalten sein. Apps sollten so weit wie möglich voneinander entkoppelt sein, aber es wird eindeutig Abhängigkeiten geben. Das Ziel sollte also sein, den Abhängigkeitsgraphen so einfach und vernünftig wie möglich zu halten.

Ich bevorzuge es, alle Vorlagen für ein Projekt in einem einzigen projektweiten Templates-Verzeichnis mit einem Unterverzeichnis für jede App zu behalten (ein Vorlagenunterverzeichnis für jede App ist eine sehr starke Konvention in Django, da es den Vorlagennamen vermeidet) Kollisionen zwischen Apps). Der Grund für ein einzelnes projektweites Vorlagenverzeichnis ist, dass Vorlagen, Vorlagenvererbungsbäume und Blocknamen ziemlich projektspezifisch sein können. Daher ist es schwierig, "Standard" -App-Vorlagen bereitzustellen, die an jedes Projekt angeschlossen werden können.Es gab einige Versuche, sich mit den Standard-Namenskonventionen für base-site-weite Templates und die von ihnen definierten Blöcke zu befassen, aber ich habe noch keinen Standard-emerge gesehen (die Art, wie sie Dinge bei Pinax erledigen, ist wahrscheinlich der nächste, den wir haben Standard).

Re "String Externalisierung", wenn Sie i18n und l10n meinen, Django hat starke Unterstützung dafür und Standard-Orte, wo es die .po-Dateien setzt - überprüfen Sie die docs.

Answer 2

Diese Seite hat eine gute Arbeit von einigen meiner Fragen adressieren: http://www.b-list.org/weblog/2006/sep/10/django-tips-laying-out-application/

Im Einzelnen:

1. Um benutzerdefinierte Vorlagen-Tags oder Filter zu definieren, müssen Sie ein Unterverzeichnis in der Anwendung erstellen Verzeichnis namens templatags, und es muss eine Datei namens __init__.py enthalten, damit es als Python-Modul importiert werden kann.
2. Um Komponententests zu definieren, die von Djangos Testrahmenwerk automatisch erkannt werden, fügen Sie sie in ein Modul namens tests ein (das eine Datei namens tests.py oder ein Verzeichnis namens tests sein kann). Das Testframework findet auch alle Doctests in diesem Modul, aber der bevorzugte Ort für diese sind natürlich die Docstrings der Klassen oder Funktionen, die sie testen sollen.
3. Um benutzerdefinierte SQL zur Verfügung zu stellen, die sofort nach der Installation Ihrer Anwendung ausgeführt wird, erstellen Sie ein Unterverzeichnis namens sql im Verzeichnis der Anwendung; Die Dateinamen sollten mit den Namen der Modelle übereinstimmen, auf deren Tabellen sie ausgeführt werden. Wenn Sie zum Beispiel eine App namens weblog mit einem Modell namens Entry haben, kann die Datei sql/entry.sql im Verzeichnis der App verwendet werden, um Daten in der Tabelle entries zu ändern oder einzufügen, sobald sie erstellt wurde.

Die Notiz tests.py und Tests (das Verzeichnis) gilt auch für Modelle, die das Problem, Art und Weise zu viele Tests (oder Modelle) für eine Datei hilft adressieren.

Ich würde immer noch gerne einige Beispiele/Vorschläge für App/Projekt Breakdown sehen, und große Django-Sites, die gut funktionieren.

Answer 3

Die Pinax project basiert auf der Idee von kleinen wiederverwendbaren Apps, die sich leicht zu einem Projekt zusammenfügen lassen. Sie haben das Projekt Cloud 27 als Demo-Projekt verwendet.

Das Django-Projekt, an dem ich arbeite (Basie genannt. Es ist vor 0.1, also noch keine Verbindung.) Versucht, dem Pinax-Modell zu folgen, und bis jetzt klappt es ziemlich gut.

Answer 4

Mein derzeitiges Layout stammt von mir, weil ich eine Testversion meiner Seiten haben möchte. Das bedeutet, dass es für jede Site zwei Projekte gibt, da sie unterschiedliche Konfigurationen benötigen, und zwingt mich, alle Anwendungen aus den Projekten zu entfernen.

Ich habe zwei Ordner erstellt: $ APP_ROOT/devel und $ APP_ROOT/prod. Diese enthalten alle Apps. Mit der Quellcodeverwaltung (in meinem Fall git) habe ich die Apps in der HEAD Revision in devel, während die Apps in prod mit dem PROD Tag verbunden sind. Die Vorlagen haben auch ihren eigenen Ordner mit dem gleichen Layout wie die Apps.

Jetzt bin ich in der Lage, meine gesamte Entwicklung im Ordner devel-apps und dem passenden Template-Ordner durchzuführen. Wenn ich etwas habe, mit dem ich zufrieden bin, kennzeichne ich diese Revision und aktualisiere Prod.

Answer 5

fand ich Zachary Layout sehr nützlich Zachary Voase’s Blog » Django Project Conventions, Revisited.

Answer 6

Ich mag Randall Degges' Beitrag zu diesem Thema wirklich. Er lässt Informationen darüber aus, wie man die Einstellungsdateien zusammenkleben kann, aber ich werde einen Beitrag dazu haben, den ich verlinken kann, aber für den Moment kann jeder my repo auschecken, wo ich eine Richtung in die Readme-Datei einfüge.