• liegen in der Regel in models.py
• definieren die Grundobjekte
  • eigentlich sind sie die Datenbankdarstellung
  • bringen Methoden mit um Objekte aus der Datenbank zu erstellen/zu filtern oder darin zu speichern
  • ein Objekt enthält die Daten eines „Objektes“ in der Datenbank/ist ein Datensatz
• basierend darauf kann das Admin-Interface generiert werden

• in der Regel in admin.py definiert
• stellt basierend auf den Models die admin.py zur Verfügung
  • definiert welche Tabellen eine Admin-Tabelle bekommen sollen

from django.contrib import admin

from . import models

admin.site.register(models.Artikel)

• in diesem Fall wird für die Tabelle Artikel (basierend auf den Feldern) im Admin-Interface eingeblendet

• sind in urls.py
• macht das Mapping zwischen URL/Pfaden und Call-Back-Funktionen aka. Views

from django.urls import path
from . import views

urlpatterns = [
    path("<int:id>/something/, views.something, name="mysomething")
]

Die entsprechende view sieht so aus:

def something(request, id):
    pass

• request enthält den Request
• was auch immer in <> in der View steht wird an die aufgerufene Funktion als Parameter übergeben
  • in diesem Fall „id“

• in der Regel in views.py
• enthält die Funktionen die definieren was gesendet werden soll
  • also zum Beispiel ob eine Seite anhand eines Templates gerendert werden soll oder json zurück gegeben werden soll
• was auch immer die Funktionen hier zurückgeben (in return) wird als Antwort gesendet

def something(request, id):
    return HttpResponse(id)

• der erste Parameter den eine view bekommt ist der Original-Request
• die nachfolgenden sind die URL-Parameter (die in den views mit <> angegeben werden)
• return gibt den Response zurück
  • HttpResponse gibt einen rohen HttpRepsponse zurück und was auch immer der Klasse übergeben wird
  • render ist eine Methode die anhand eines Templates eine Seite rendert und diese dann zurückgibt

Gibt es nicht - muss durch if-Anweisungen abgebildet werden.

{% if Bedingung %}
      Code
{% else %}
      Code
{% endif %}

Ab django 1.4 existiert auch {% elif %}, voher kann man sich mit:

{% load assign %}
{% assign name="Variablenname" %} 0 {% endassign %}

{% if Bedingung %}
       Code
       {% assign name="Variablenname" %} 1 {% endassign %}
{% endif %}
{% if Bedingung AND Variablenname == 0 %}
       Code
       {% assign name="Variablenname" %} 1 {% endassign %}
{% endif %}
{% if Bedingung AND Variablenname == 0 %}
       Code
{% else %}
       Code
{% endif %}

Man setzt einfach eine Variable wenn ein if-Zweig durchlaufen wurde und prüft bei allen folgenden if-Anweisungen ob diese Variable auf 0 steht, steht sie auf 1, wurde bereits ein if-Zweig durchlaufen und es soll kein weiterer if-Zweig durchlaufen werden. Man erhält so eine case- oder switch-Anweisung.

• Geht standardmäßig nicht
• Kann durch django-templateaddons (Name des Paketes) nachinstalliert werden

Zuweisung:

{% assign name="Variablenname" %} 1 {% endassign %}

Auslesen:

{{ Variablenname }}

bzw. letztendlich wie jede andere interne Variable auch

Hinweis: Möglicherweise funktioniert Assign nur beim höchsten Eltern-Template (also bei Vererbung/verschachtelten Templates das Höchste - das was kein „extends“ mehr enthält)

• Placeholder lassen sich nicht auf Inhalt prüfen
  • Man kann also nichts abhängig davon machen
• Blocks lassen sich nicht auf Inhalt prüfen
  • Man kann also nichts abhängig davon machen