Django Konventionen

0 | 5162 Aufrufe
Sie können diese Wikiseite nach der Anmeldung auf Webmasterpro bearbeiten. Helfen Sie mit und verbessern Sie "Django Konventionen" mit Ihrem Wissen!

Anzeige Hier werben

Artikelserie - Wiederverwendbarkeit von Django Applikationen

Dieser Artikel ist Teil einer Artikelserie rund um die Erstellung wiederverwendbarer Django Applikationen

Konventionen

Bild zu Django Konventionen

Damit auch andere Entwickler sich schnell in deiner Anwendung orientieren können oder aber Du Dich nach ein paar Monaten immer noch zurecht findest gibt es einige Konventionen und Best Practices für Django Module. Dazu zählt zum Beispiel wie der Code in Deinen Dateien im Anwendungsordner organisiert ist oder wie die Blöcke in den Templates benannt werden. Im Folgenden werden die meisten davon angesprochen, die in der Django-Community weit verbreitet und akzeptiert sind.

Stil des Quellcodes

Von vielen Einsteigern wird die ordentliche Formatierung des Quellcodes unterschätzt. Auch wenn Python den Programmierer durch seine Eigenschaften ein wenig bei der Hand nimmt gibt es oft noch einige Dinge zu beachten. Schließlich bietet ein einheitlicher Stil unter Entwicklern eine gute Hilfestellung, wenn man unbekannten Code verstehen oder erweitern möchte. Ein paar Grundregeln die von den Django-Gründern empfohlen werden sind im Folgenden näher erläutert.

Allgemein

Die meisten Django Entwickler halten sich an die Konvention Funktionen, Variablen und Methoden jeweils klein zu schreiben und Unterstriche für die Trennung von Wörtern in Namen zu verwenden. Klassen sowie Models dagegen werden allgemein üblich mit dem CamelCase Stil benannt. Dabei fängt der Name mit einem Großbuchstaben an, es werden keine Unterstriche beim Wortwechsel verwendet sondern man schreibt den ersten Buchstaben des neuen Wortes erneut groß: RichtigerCamelCaseBezeichner.

Templates

In Templates sollten zugute der besseren Lesbarkeit Variablen mit einem Leerzeichen Platz zwischen den Klammern und dem Namen geschrieben werden. {{ var }} ist die bessere Schreibweise, wobei {{var}} zwar gültig, aber nicht besonders gut lesbar ist.

Views und mehr

Um das Erscheinungsbild von views möglichst einheitlich zu halten sollte der erste Parameter request genannt werden. Noch weitere Richtlinien findet man in der offiziellen Django Dokumentation. Dort wird unter anderem aufgeführt wie die Teile eines Models innerhalb Klasse angeordnet sein sollten um sich schnell zu recht zu finden.

Verzeichnisstruktur

Auch für die Struktur der Dateien gibt es einige Konventionen die sich lohnen eingehalten zu werden. Der schnellen Navigation innerhalb des Quellcodes steht dann nichts mehr entgegen.

Das Verzeichnis in dem das Django Modul gespeichert wird sollte je nach Bedarf folgende Dateien enthalten:

models.py: Wenn man die Datenbankanbindung von Django erledigen lässt, sollte man die Models in der models.py Datei speichern. Dies wird teilweise ja bereits von Django erzwungen, da das Framework die Models sonst nicht finden kann.

managers.py: Sind eigene Managers oder Querysets für die Models notwendig solltest man diese in der managers.py ablegen. Die Datei kann man dann in der models.py importieren und dort verwenden.

views.py / views Verzeichnis: Sogut wie jede Applikation wird die ein oder andere view benötigen. Diese werden normalerweise in der views.py Datei untergebracht. Ist die Anwendung entsprechend umfangreich können Diese auch in einem eigenen Unterordner gesammelt werden.

forms.py: Verwendet die Applikation das forms Modul von Django sollten die Forms und ModelForms in forms.py oder wiederum in einem gleichnamigen Unterverzeichnis gespeichert werden.

urls.py: Bietet die Anwendung bereits vorgefertigte Urlmappings an, sollten diese in der urls.py untergebracht werden. Verwendet man benannte Urls ist es auch empfehlenswert ein einheitliches Präfix für die Namen zu verwenden. So werden Namenskollisionen mit anderen Applikationen vermieden. Ein mögliches Schema für deren Namen könnte APP_MODEL_VIEW sein. Möchte man z.B. einen Eintrag in der Detailansicht aufrufen ist schnell ersichtlich, dass man diesen über die Url mit dem Namen blog_entry_detail erreichen kann.

admin.py: In der admin.py Datei werden die Admin Klassen der Applikation untergebracht. Diese Klassen sollten genauso wie das Model heißen, nur mit einem Admin als angehängt. Beispiel: EntryAdmin.

middleware.py / context_processors.py / feeds.py: Benötigte Middleware, Contextprocessors und Newsfeeds finden in der middleware.py, context_processors.py bzw. feeds.py platz.

Templates

Achtet man auch bei den Templates darauf, dass sie in einer einheitlichen Art und Weise erstellt werden kann man sich viel Schreibarbeit sparen. Sollen die Anwendungsspezifischen Templates von Django gefunden werden, müssen diese in einem Unterordner mit dem Namen templates/ untergebracht werden. Wird nun ein Template von Django geladen, sucht es zuerst in den Verzeichnissen die in der TEMPLATES_DIRS Einstellung hinterlegt sind. Existiert dort kein Template mit dem angeforderten Namen, durchforstet Django die template Verzeichnisse der installierten Applikationen. So können auf einfache Weiße vorgefertigte Templates mit der Anwendung ausgeliefert werden um ein besseres Out-of-the-Box Feeling zu erhalten. Hält man nun noch einige Konventionen bei der Benennung der Templateblöcke ein, so kann man mit sehr wenig Aufwand die mitgelieferten Templates in einem eigenständigen Projekt weiter nutzen und sie dennoch an das eigene Look&Feel anpassen.

{% block title %}: Der Inhalt dieses Blocks sollte in einem Eltern Template innerhalb des title HTML-Tags dargestellt werden. So lässt sich für jede Seite ein individueller Titel erstellen.

{% block extra_head %}: Mit diesem Block kann man zusätzliche Informationen in den head Tag einfügen. So lassen sich zusätzliche Stylesheets oder Javascript Dateien einbinden. Sollte man von einem Template erben, dass bereits den extra_head Block überschreibt kann es eventuell wichtig sein, die Inhalte des Elterntemplates mit {{ block.super }} neu darzustellen und somit nicht zu überschreiben.

{% block body %}: Dieser Block sollte den kompletten body Tag beinhalten. So kann man, wenn nötig die gesamte Seitestruktur überschreiben und nicht nur den Seitenspezifischen Inhalt.

{% block menu %}: Im menu Block sollte man die globale Navigation unterbringen.

{% block content %}: Der wohl wichtigste Block ist der content Block. In ihn sollte der Inhalt geschrieben werden der von Seite zu Seite variiert. So braucht eine einfache Unterseite nur diesen Block zu überschreiben und kann ganz simpel das Design der gesamten Seite beibehalten.

Um nun die mitgelieferten Templates einer Anwendung wie oben besprochen nutzen zu können muss nur ein einzelnes Template der Applikation überschrieben werden. Voraussetzung dafür ist jedoch, dass alle anderen von diesem die Struktur erben. Ersetzt man diese Basisdatei (z.B. myapp/base.html) mit dem Inhalt des folgenden Codeblocks, so werden alle Inhalte mit dem gleichen Design wie der Rest der Seite ausgeliefert.

myapp/base.html: erbe von der basisstruktur des projektes  
HTML
1
{% extends "base.html" %}

Weitere Informationen

Die hier vorgestellten Konventionen zur Django Entwicklung wurden teilweise von den Django Gründern selbst vorgeschlagen oder sind Bemühungen aktiver Community Mitglieder eine gewissen Standard zu etablieren. Einige ausführlichere Behandlungen dieses Themas, dafür aber auf englisch finden sich auf den folgenden Seiten:

Django Conventions Project: Eric Holscher hat in seinem Blog eine der umfangreichsten Sammlungen an Vorschlägen für einheitliche Django Module veröffentlicht. Außerdem hat er versucht solche Konventionen auch für ganze Projekte mit Django zu finden.

Contributing to Django: In der Django Dokumentation finden sich einige Regeln die man beachten sollte wenn man Code, Templates oder Dokumentation zum Framework beitragen möchte. Vorallem die Sektion coding style kann aber wohl auch allgemeingültig für alle wiederverwendbaren Django Applikationen verstanden werden.

PEP 8: Im Python Enhencement Proposal 8 werden einige Richtlinien für Quellcode vorgestellt die allgemeingültig für alle Python Entwickler empfohlen werden.


Wikiseite bearbeiten

Diese Seite kann von jedem registrierten Benutzer bearbeitet werden. Bisher haben 3 Personen an der Seite "Django Konventionen" mitgewirkt.

Sie haben einen Fehler entdeckt oder möchten etwas ergänzen? Dann können Sie nach der Anmeldung "Django Konventionen" hier bearbeiten.

Mitarbeiter
  • Ich bin zur Zeit Informatik Student und arbeite als freiberuflicher Programmierer. Die meisten Projekte verwirkliche ich mit Python und Django. Aber auch PHP zählt zu den Programmiersprachen die ich gelegentlich einsetze. Außerdem bin ich großer Fan von OpenSource und Linux.
  • Meine Schwerpunkte liegen im Bereich Grafikdesign, SEO und Management. Seit sieben Jahren bin ich als Geschäftsführer der Team23 GbR tätig, die Webdesign in Augsburg anbietet, sowie Webmasterpro.de betreut.
  • Kinderturnen - Sport Spiele für Kinder