Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

De:Code Richtlinien für Openslides

Norman Jäckel edited this page · 4 revisions

Um die Entwicklung von OpenSlides unter einen Hut zu bekommen und neuen Entwicklern einen möglichst einfachen Einstieg in die Codebasis zu ermöglichen, sollen folgende Regeln eingehalten werden.

Allgemeines

  • Soweit noch keine Regeln definiert sind, entscheidet über die Aufnahme von Code sowie dessen Style der Maintainer. Er berät sich hierzu mit dem Coreteam.
  • Wir halten uns an PEP 8 mit der Ausnahme, dass Zeilen eine Länge von 150 Zeichen haben dürfen. Es sollte versucht werden, mit 79 Zeichen auszukommen. Des weiteren halten wir uns an den Codingstyle von Django. Für die urls.py gilt dies derzeit noch nicht.
  • Wir streben 100 % Unittests an. Wer eine neue Funktion, View, etc. einbringt, soll auch entsprechende Unittests schreiben.

Repository-Struktur

  • Die oberste Struktur unseres Repositories richtet sich nach http://kennethreitz.com/repository-structure-and-python.html.
  • Die Funktionalität von OpenSlides ist in verschiedene Apps aufgeteilt. Für diese existiert jeweils ein Unterordner im openslides-Modul.
    • OpenSlides-Core:
      • projector: Funktionalität für Slides und das Ausliefern der Beameransicht
      • dashboard: Funktionalität für Widgets einschließlich custom slides, overlays, countdown
      • account: Authentifizierung und Benutzereinstellungsseite, Personal-Widget
      • person: Funktionalität für Personen
      • config: Funktionalität für Konfigurationseinträge aller Apps
      • general: Globale Informationen zur Instanz, z. B. Willkommenswidget, grundlegende Konfigurationseinträge (z. B. Name, Zeit und Ort der Veranstaltung), Versionsseite
    • OpenSlides-Modules:
      • agenda
      • motion
      • assignment
      • participant
      • poll ?
      • file mediafile
    • Neben App-Ordnern existieren folgende Unterordner:
      • utils: Enthält Funktionalität welche potentiell von mehreren Apps benötigt wird.
      • locale: Enthält die Übersetzungen für die OpenSlides Kern Apps.
      • statics: Enthält statische Dateien für die OpenSlides Kern und ? Apps, welche vom Webserver ausgeliefert werden müssen. Dateien die nur von einer App benötigt werden, gehören in die jeweilige App.
      • templates: Enthält die Base-Templates für OpenSlides.
  • Jede einzelne App setzt sich aus verschiedenen Dateien zusammen, welche teilweise nur optional sind.
    • init.py: Muss vorhanden sein. Kann App spezifische Variablen setzten, welche von OpenSlides ausgelesen werden. Momentan ist dies nur 'NAME'. Wenn slides.py oder signales.py vorhanden ist, muss die jeweilige Datei importiert werden.
    • modules.py: Muss vorhanden sein. Enthält nur die Django-Module. Darf beim Importieren keine Dateien der selben App importieren. (Norman: Warum nicht? Ist leider nicht immer durchzuhalten. Z. B. wollen exceptions und signale importiert werden.) Die Reihenfolge der Methoden von Modellen richtet sich nach https://docs.djangoproject.com/en/1.4/internals/contributing/writing-code/coding-style/#model-style
    • forms.py: Enthält nur die Django-Formulare. Darf beim importieren nicht views.py importieren.
    • slides.py: Enthält Funktionalität für die Anzeige auf den Projektor.
    • signals.py: Enthält von der App definierte Signale, sowie Funktionen die auf vorhandenen Signale hören soll.
    • urls.py: Enthält die urls für die App.
    • views.py: Enhält die views für die App. Weiterhin folgende weitere Funktionen. * register_tab: Bekommt 'request' als einziges Argument und gibt ein Tab Objekt[1] zurück. [1] Siehe openslides.utils.template.Tab * get_widgets: Bekommt 'request' als einziges Argument und gibt eine Liste mit Widget Objekten[1] zurück. [1] Siehe openslides.projector.projector.Widget (Soll nach openslides.dashboard verschoben werden)
    • exceptions.py: Enthält von OpenSlidesError abgeleitete eigene Ausnahmen der App.

Views

  1. Wir verwenden Class Based Views. Diese sollen immer aus openslides.utils.views importiert werden.
  2. Eine View zum Erstellen eines Objekts heißt OBJEKTNAMECreateView
  3. Eine View zum Bearbeiten eines Objekts heißt OBJEKTNAMEUpdateView

Urls

  1. Jede URL hat einen Namen und wird im Code nur durch den Namen referenziert.
  2. Der Name der URL besteht nur aus Kleinbuchstaben und dem Unterstrich und setzt sich zusammen aus dem App, dem Model und der View, z. B. agenda_item_list.
  3. Ist der Name der App und der Name des Models identisch, setzt sich der Name aus der App und der View zusammen, z.B motion_list oder motionpoll_update.
  4. Die URL richtet sich nach der englischen Bezeichnung des Buttons im Template, die ihn auslöst. Der Name der Url richtet sich nach dem Namen der zugehörigen View und dem Namen des Templates.

Templates

  1. Ein Template für eine View befindet sich in einem Ordner "templates/APPNAME". Der Dateiname ist in Kleinbuchstaben, Worte sind mit Unterstrichen getrennt und enden auf ".html".
  2. Die Templatenamen sollte dem automatisch generierten Namen der Django-Richtlinien entsprechen, also: APP/MODEL_WO_WAS.html (WO: z.B. slide; WAS: z.B. detail, list, form, csv_import...). Beispiele:
motion/motion_slide.html
motion/motion_list.html
motion/motionpoll_form.html

Importe

  1. Der Name _ ist bei uns durch ugettext definiert. Andere Übersetzungsfunktionen, selbst wenn ugettext in der Datei nicht verwendet werden, müssen ausgeschrieben werden.

Personenverwaltung

Erster Vorschlag: http://piratepad.net/Ohh1RBp1lt Vertretungsfrage: Keine Verwendung eines manipulierten Request.users. Der Request.user ist immer der angemeldete tatsächliche Benutzer. Es gibt jedoch für Formulare ein VertretungsField bei welchem aus allen vertretbaren Personen ausgewählt werden kann. Ist diese keine, wird nichts angezeigt. Auch natürliche Personen können vertreten werden. (Gründe: Die App soll entscheiden können, ob jemand auch als Vertreter agieren darf oder nicht. Z. B. nicht beim Formular Passwort ändern.)

Antragsverwaltung

Anträge

Attribute:

  • Ersteller -> Many2Many(Person)
  • Unterstützer -> Many2Many(Person) (In eins mit Ersteller)
  • Status (variabel definierbare Werte)
  • Aktive Version (passenden Namen finden)
  • log (übersetzbar)
  • Präfix/Bezeichner (unique = True)
  • Kategorie (Foreinkey) Null=True
  • Verfahrens Vorschläge (definierbare Werte)
  • Dupliziert woher (parrent)

Änderungsantrag

Attribute:

Antrags-Version

Attribute:

  • Titel
  • Text
  • Begründung
  • Versions-Präfix/Bezeichner
  • Versionsbegründung
  • Motion = ForeinKey(Antrag)
  • Rejected
  • Erstellungszeit

Kategorie

Attribute:

  • (Voller) Name
  • Präfix

Kommentar

Attribute:

  • Verweis auf Antrags-Version.
  • Verweis auf Zeile/Absatz(?)
  • Ersteller (Person)
  • Zeit
  • Text

Funktionalität

  • Es kann konfiguriert werden ob bei einer Änderung eine neue Version angelegt werden muss, angelegt werden kann, oder immer in die alte Version gespeichert wird.
  • Das zulässigkeitssystem kann ausgeschaltet werden (P! Gibt es den Status nicht zugelassen?)
  • Einstellung ob Antragseintragende Person die Antragssteller und Unterstützer selbst definieren kann.
  • Anzahl nötige Unterstützer kann ausgewählt werden. Bei 0 ist Unterstützersystem deaktiviert.
  • Präfix-Config: freies Textfeld oder Numerische oder Alphanumerisch mit Vorauswahl der Buchstaben
  • Wenn ich eine Kategorie auswähle bekommt er eine Nummer.
  • Wenn das Kategorisierungssystem abgeschalten ist, gibt es einen Knopf "Nummer setzten", ggf. mit dem Status verbinden
  • Gibt es keine, oder nur eine Kategorie, fällt die Funktionalität weg.
  • Art der Antrags-Stadi werden in der Settings konfiguriert. Standardmäßig sind mehrere Definiert, können in der Konfig ausgewählt werden.
  • Recht Kommentare zu schreiben und zu lesen.
  • Antrag Duplizieren ( Mit verweis woher, wohin)
  • Änderungsantrag: ** Es gibt keine Änderungsanträge zu Änderungsanträgen ** Antrag mit allen Änderungsanträgen als Übersicht, mit Sortierung(Antragssteller, Empfehlung, etc)

Fragen

  • Was passiert wenn ich bei den Phasen(Stadien) Kein Zugelassen, oder einen anderen Begriff habe?
  • Kommentare auf alte Versionen.
Something went wrong with that request. Please try again.