Öffnen Sie http://127.0.0.1:8000/account/login/ in Ihrem Browser. Sie sollten eine Anmeldeseite sehen. Geben Sie einen gültigen Benutzernamen und ein Passwort ein. Sie werden Folgendes sehen:

Sie können sehen, dass der Abschnitt „Mein Dashboard“ mit CSS hervorgehoben ist, da er über eine Klasse verfügt ausgewählt. Da der Benutzer authentifiziert wurde, wird der Benutzername auf der rechten Seite der Kopfzeile angezeigt. Klicken Sie auf den Link Ausloggen. Sie sehen die folgende Seite:

Auf dieser Seite können Sie erkennen, dass der Benutzer abgemeldet ist und daher das Website-Menü nicht mehr angezeigt wird. Der Link auf der rechten Seite der Kopfzeile wird jetzt angezeigt Anmeldung.

Wenn Sie die Abmeldeseite der Django-Administratorseite und nicht Ihre eigene Abmeldeseite sehen, überprüfen Sie Ihre INSTALLED_APPS-Einstellungen und stellen Sie sicher, dass dies der Fall ist django.contrib.admin ist danach Konto. Beide Vorlagen befinden sich im selben relativen Pfad und der Django-Vorlagenlader verwendet die erste, die er findet.

Hauptsächlich für die Entwicklung von Benutzeroberflächen. Um es zu verwenden, müssen Sie einen Modelltyp erstellen, der den vollständigen Status des Programms darstellt, einen Nachrichtentyp, der externe Umgebungsereignisse beschreibt, auf die das Programm mit einer Statusänderung reagieren muss, und eine Aktualisierungsfunktion, die einen neuen Status des Programms erstellt aus dem alten Status und der Nachricht sowie einer Ansichtsfunktion, die basierend auf dem Status des Programms die erforderlichen Auswirkungen auf die externe Umgebung berechnet, die Ereignisse vom Typ Nachricht generieren. Das Muster ist sehr praktisch, hat aber einen kleinen Nachteil: Es lässt sich nicht beschreiben, welche Ereignisse für bestimmte Programmzustände sinnvoll sind.

Ein ähnliches Problem entsteht (und wird gelöst), wenn das State OO-Muster verwendet wird.

Die Elm-Sprache ist einfach, aber sehr streng – sie prüft, ob die Updater-Funktion irgendwie alle möglichen Kombinationen von Modellstatus- und Nachrichtenereignissen verarbeitet. Daher müssen Sie zusätzlichen, wenn auch trivialen Code schreiben, der das Modell normalerweise unverändert lässt. Ich möchte zeigen, wie dies in komplexeren Sprachen vermieden werden kann – Idris, Scala, C++ und Haskell.

Der gesamte hier gezeigte Code steht zum Experimentieren auf GitHub zur Verfügung. Schauen wir uns die interessantesten Orte an.

MUV ist ein Konstruktor. Es akzeptiert folgende Parameter: model – der Anfangszustand des Programms, updater – eine Funktion zum Aktualisieren des Zustands bei einem externen Ereignis und view – eine Funktion zum Erstellen einer externen Ansicht. Beachten Sie, dass der Typ der Aktualisierungs- und Ansichtsfunktionen vom Wert des Modells abhängt (unter Verwendung der msg-Funktion aus den Typparametern).

Sehen wir uns nun an, wie diese Anwendung gestartet wird

MuvRun: (Application modelType msgType IO) -> IO a muvRun (MUV model updater view) = do msg<- view model muvRun (MUV (updater model msg) updater view)
Wir haben eine Eingabe-/Ausgabeoperation als externe Darstellung (Ansicht) gewählt (in Idris, wie auch in Haskell, sind Eingabe-/Ausgabeoperationen erstklassige Werte; damit sie ausgeführt werden können, müssen zusätzliche Aktionen durchgeführt werden, die normalerweise eine solche Operation zurückgeben aus der Hauptfunktion).

Kurz über IO

Bei der Ausführung einer Operation vom Typ (IO a) treten einige Auswirkungen auf die Außenwelt auf, möglicherweise ist sie leer, und ein Wert vom Typ a wird an das Programm zurückgegeben, aber die Funktionen der Standardbibliothek sind so konzipiert, dass dies möglich ist nur verarbeitet werden, indem ein neuer Wert vom Typ IO b generiert wird. Auf diese Weise werden reine Funktionen von Funktionen mit Nebenwirkungen getrennt. Das ist für viele Programmierer ungewöhnlich, hilft aber dabei, zuverlässigeren Code zu schreiben.

Beschreiben wir nun die Arten von Entitäten, mit denen wir arbeiten werden

Datenmodell = Abgemeldet | Angemeldete String-Daten MsgOuted = Login-String-Daten MsgIned = Logout | Gruß insgesamt msgType: Modell -> Typ msgType Logouted = MsgOuted msgType (Logined _) = MsgIned
Hier beschreiben wir einen Modelltyp, der das Vorhandensein von zwei Schnittstellenzuständen widerspiegelt: Der Benutzer ist nicht angemeldet, und der Benutzer mit einem Namen vom Typ String ist angemeldet.

Als nächstes beschreiben wir zwei verschiedene Arten von Nachrichten, die für verschiedene Varianten des Modells relevant sind – wenn wir abgemeldet sind, können wir uns nur unter einem bestimmten Namen anmelden, und wenn wir bereits angemeldet sind, können wir uns entweder abmelden oder Hallo sagen. Idris ist eine stark typisierte Sprache, die die Möglichkeit einer Vermischung verschiedener Typen nicht zulässt.

Und schließlich eine Funktion, die die Übereinstimmung des Modellwerts mit dem Nachrichtentyp festlegt.

Die Funktion wird als vollständig deklariert, d. h. sie sollte nicht abstürzen oder einfrieren. Der Compiler wird versuchen, dies zu überwachen. msgType wird zur Kompilierungszeit aufgerufen und seine Gesamtheit bedeutet, dass die Kompilierung aufgrund unseres Fehlers nicht einfriert, obwohl nicht garantiert werden kann, dass die Ausführung dieser Funktion die Systemressourcen erschöpft.
Es ist auch garantiert, dass „rm -rf /“ nicht ausgeführt wird, da in seiner Signatur kein IO enthalten ist.

Beschreiben wir den Updater:

Total updater: (m:Model) -> (msgType m) -> Model updater Logouted (Login name) = Angemeldeter Name updater (Login name) Logout = Logouted updater (Login name) Greet = Logined name
Ich denke, die Logik dieser Funktion ist klar. Ich möchte noch einmal auf die Gesamtheit hinweisen – das bedeutet, dass der Idris-Compiler überprüft, ob wir alle vom Typsystem zugelassenen Alternativen berücksichtigt haben. Elm führt diese Prüfung ebenfalls durch, kann jedoch nicht wissen, dass wir uns nicht abmelden können, wenn wir noch nicht angemeldet sind, und erfordert eine explizite Verarbeitung der Bedingung

Updater abgemeldet Abmelden = ???
Idris wird bei einer unnötigen Prüfung Typkonflikte feststellen.

Kommen wir nun zur Ansicht – wie in der Benutzeroberfläche üblich, wird dies der schwierigste Teil des Codes sein.

Total loginPage: IO MsgOuted loginPage = do putStr "Login: " map Login getLine total genMsg: String -> MsgIned genMsg "" = Logout genMsg _ = Greet total workPage: String -> IO MsgIned workPage name = do putStr ("Hallo, " ++ Name ++ „\n“) putStr „Geben Sie eine leere Zeichenfolge für die Abmeldung oder eine nicht leere Zeichenfolge für die Begrüßung ein\n“ map genMsg getLine total view: (m: Model) -> IO (msgType m) view Logouted = loginPage view (Angemeldeter Name ) = Arbeitsseitenname
Die Ansicht muss eine E/A-Operation erstellen, die Nachrichten zurückgibt, deren Typ wiederum vom Wert des Modells abhängt. Wir haben zwei Möglichkeiten: loginPage, das eine „Login:“-Nachricht druckt, eine Zeichenfolge von der Tastatur liest und sie in eine Login-Nachricht einschließt, und workPage mit einem Benutzernamen-Parameter, der eine Begrüßung druckt und verschiedene Nachrichten (jedoch vom gleichen Typ) zurückgibt - MsgIned), abhängig davon, ob der Benutzer eine leere oder eine nicht leere Zeichenfolge eingibt. view gibt abhängig vom Wert des Modells eine dieser Operationen zurück und der Compiler überprüft deren Typ, auch wenn er unterschiedlich ist.

Jetzt können wir unsere Anwendung erstellen und ausführen

App: Anwendungsmodell Main.msgType IO app = MUV Abgemeldete Updater-Ansicht main: IO () main = muvRun app
Hier sollte ein subtiler Punkt beachtet werden: Die Funktion muvRun kehrt zurück IO a, wobei a nicht angegeben wurde und der Wert main vom Typ ist IO(), Wo () ist der Name eines Typs, der üblicherweise aufgerufen wird Einheit, das einen einzelnen Wert hat, auch als leeres Tupel geschrieben () . Aber der Compiler kann damit problemlos umgehen. Ersetzen Sie stattdessen a().

Scala und pfadabhängige Typen

Versiegelte abstrakte Klasse MsgLogouted-Fallklasse Login(name: String) erweitert MsgLogouted-versiegelte abstrakte Klasse MsgLogined-Fallklasse Logout() erweitert MsgLogined-Fallklasse Greet() erweitert MsgLogined-Abstraktklasse View ( def run() : Msg ) versiegelte abstrakte Klasse Model ( Typ Message def view() : View ) case class Logouted() erweitert Model ( type Message = MsgLogined override def view() : View .... ) case class Logined(name: String) erweitert Model ( type Message = MsgLogined override def view( ): Sicht .... )
Algebraische Typen in Scala werden durch Vererbung modelliert. Der Typ entspricht einigen versiegelte abstrakte Klasse, und jeder Konstruktor erbte davon Fallklasse. Wir werden versuchen, sie genau als algebraische Typen zu verwenden und alle Variablen als zum übergeordneten Element gehörend zu beschreiben versiegelte abstrakte Klasse.

Die Klassen MsgLogined und MsgLogouted in unserem Programm haben keinen gemeinsamen Vorfahren. Die Ansichtsfunktion musste auf verschiedene Klassen des Modells verteilt werden, um Zugriff auf einen bestimmten Nachrichtentyp zu haben. Das hat seine Vorteile, die OO-Anhänger zu schätzen wissen – der Code ist nach Geschäftslogik gruppiert, alles, was mit einem Anwendungsfall zu tun hat, ist in der Nähe. Aber ich würde die Ansicht lieber in eine separate Funktion aufteilen, deren Entwicklung auf eine andere Person übertragen werden könnte.

Jetzt implementieren wir den Updater

Object Updater ( def update(model: Model)(msg: model.Message) : Model = ( model match ( case Logouted() => msg match ( case Login(name) => Logined(name) ) case Logined(name) => msg match ( case Logout() => Logouted() case Greet() => model ) ) ) )
Hier verwenden wir pfadabhängige Typen, um den Typ des zweiten Arguments ausgehend vom Wert des ersten zu beschreiben. Damit Scala solche Abhängigkeiten akzeptiert, müssen Funktionen in Curry-Form beschrieben werden, also als Funktion aus dem ersten Argument, die eine Funktion aus dem zweiten Argument zurückgibt. Leider führt Scala zu diesem Zeitpunkt nicht viele Typprüfungen durch, für die der Compiler über genügend Informationen verfügt.

Lassen Sie uns nun eine vollständige Implementierung des Modells und der Ansicht geben

Die Fallklasse Logouted() erweitert das Modell ( type Message = MsgLogouted override def view() : View = new View ( override def run() = ( println("Enter name ") val name = scala.io.StdIn.readLine() Login (name) ) ) case class Logined(name: String) erweitert Model ( type Message = MsgLogined override def view() : View = new View ( override def run() = ( println(s"Hallo, $name") println ( „Leere Zeichenfolge zum Abmelden, keine leere Zeichenfolge zur Begrüßung.“) scala.io.StdIn.readLine() match ( case „“ => Logout() case _ => Greet() ) ) ) abstract class View ( def run( ) : Msg ) Objekt-Viewer ( def view(model: Model): View = ( model.view() ) )
Der Rückgabetyp einer Ansichtsfunktion hängt von der Instanz ihres Arguments ab. Aber für die Umsetzung kommt es auf das Modell an.

Die so erstellte Anwendung wird wie folgt gestartet:

Objekt Main ( import scala.annotation.tailrec @tailrec def Process(m: Model) ( val msg = Viewer.view(m).run() Process(Updater.update(m)(msg)) ) def main(args: Array) = ( Process(Logouted()) ) )
Der Code des Laufzeitsystems weiß somit nichts über die interne Struktur von Modellen und Nachrichtentypen, der Compiler kann jedoch prüfen, ob die Nachricht zum aktuellen Modell passt.

Hier benötigten wir nicht alle Fähigkeiten, die pfadabhängige Typen bieten. Interessante Eigenschaften ergeben sich, wenn wir parallel mit mehreren Instanzen von Model-Updater-View-Systemen arbeiten, beispielsweise bei der Simulation einer Multi-Agenten-Welt (die Ansicht würde dann den Einfluss des Agenten auf die Welt und den Erhalt von Feedback darstellen). In diesem Fall überprüfte der Compiler, ob die Nachricht von genau dem Agenten verarbeitet wurde, für den sie bestimmt war, obwohl alle Agenten den gleichen Typ haben.

C++

Algebraische Typen können auf die gleiche Weise wie in Scala implementiert werden – eine abstrakte Klasse entspricht einem Typ und konkrete Nachkommen entsprechen Konstruktoren (nennen wir sie „Konstruktorklassen“, um sie nicht mit gewöhnlichen C++-Konstruktoren zu verwechseln) der Algebra Typ.

C++ unterstützt pfadabhängige Typen, aber der Compiler kann den Typ nicht abstrakt verwenden, ohne den tatsächlichen Typ zu kennen, dem er zugeordnet ist. Daher ist es unmöglich, Model-Updater-View mit ihrer Hilfe zu implementieren.

Aber C++ verfügt über ein leistungsstarkes Vorlagensystem. Die Abhängigkeit des Typs vom Modellwert kann in einem Vorlagenparameter einer spezialisierten Version des Ausführungssystems ausgeblendet werden.

Struct Processor ( virtual const Processor *next() const = 0; ); Vorlage struct ProcessorImpl: öffentlicher Prozessor ( const CurModel * model; ProcessorImpl (const CurModel* m) : model(m) ( ); const Prozessor *next() const ( const View * view = model->view(); const typename CurModel::Message * msg = view->run(); Ansicht löschen; const Model * newModel = msg->process(model); Nachricht löschen; return newModel->processor(); ) );
Wir beschreiben ein abstraktes Ausführungssystem mit einer einzigen Methode, um alles zu tun, was erforderlich ist, und ein neues Ausführungssystem zurückzugeben, das für die nächste Iteration geeignet ist. Die spezifische Version verfügt über einen Vorlagenparameter und wird für jede „Konstruktorklasse“ des Modells spezialisiert. Hierbei ist es wichtig, dass alle Eigenschaften des CurModel-Typs während der Spezialisierung der Vorlage mit einem bestimmten Typparameter überprüft werden und zum Zeitpunkt der Kompilierung der Vorlage selbst nicht beschrieben werden müssen (obwohl dies möglich ist). Konzepte oder andere Arten der Implementierung von Typklassen). Scala verfügt auch über ein recht leistungsfähiges System parametrisierter Typen, überprüft jedoch die Eigenschaften von Parametertypen während der Kompilierung des parametrisierten Typs. Dort ist die Implementierung eines solchen Musters schwierig, aber dank der Unterstützung von Typklassen möglich.

Beschreiben wir das Modell.

Struct Model ( virtual ~Model() (); virtual const Processor *processor() const = 0; ); struct Angemeldet: öffentliches Modell ( struct Message ( const virtual Model * Process(const Logined * m) const = 0; virtual ~Message() (); struct Logout: öffentliche Nachricht ( const Model * Process(const Logined * m) const; struct Greet: public Message ( const Model * Process(const Logined * m) const; ); const std::string name; (...); const-Ansicht * view() const ( return new LoginedView(name); ); const Processor *processor() const ( neues ProcessorImpl zurückgeben (Das); (...); const-Ansicht ); ); struct Logouted: public Model ( struct Message ( const virtual Model * Process(const Logouted * m) const = 0; virtual ~Message() (); struct Login: public Message ( const std::string name; Login(std :: string lname) : name(lname) ( ); const Model * Process(const Logouted * m) const ; * view() const ( return new LogoutedView(); ); const Processor *processor() const ( neues ProcessorImpl zurückgeben
(Das);

); );

Const Model * Logouted::Login::process(const Logouted * m) const ( delete m; return new Logined(name); ); const Model * Logined::Logout::process(const Logined * m) const ( delete m; return new Logouted(); ); const Model * Logined::Greet::process(const Logined * m) const ( return m; );
Lassen Sie uns nun alles zusammenstellen, was mit der Ansicht zusammenhängt, einschließlich der internen Einheiten der Modelle

Vorlage struct View ( virtual const Message * run() const = 0; virtual ~View () (); ); struct Logined: public Model ( struct LoginedView: public View ( const std::string name; LoginedView(std::string lname) : name(lname) (); virtual const Message * run() const ( char buf; printf("Hallo %s", name.c_str()) ; fgets(buf, 15, stdin); return (*buf == 0 || *buf == "\n" || *buf == "\r") ? (new Logout()) : static_cast (neuer Gruß); ); ); const-Ansicht * view() const ( return new LoginedView(name); ); ); struct Logouted: public Model ( struct LogoutedView: public View ( virtual const Message * run() const ( char buf; printf("Login: "); fgets(buf, 15, stdin); return new Login(buf); ); ); const-Ansicht * view() const ( return new LogoutedView(); ); );
Und zum Schluss schreiben wir main

Int main(int argc, char ** argv) ( const Processor * p = new ProcessorImpl (new Logouted()); while(true) ( ​​​​const Processor * pnew = p->next(); delete p; p = pnew; ) return 0; )

Und wieder Scala, dieses Mal mit Typklassen

Ähnlicher Teil des Codes

abstrakte Klasse View ( def run(): Message ) abstrakte Klasse Processor ( def next(): Processor; ) versiegelte abstrakte Klasse Model ( defprocessor(): Processor ) versiegelte abstrakte Klasse LoginedMessage-Fallklasse Logout() erweitert LoginedMessage-Fallklasse Greet( ) erweitert die LoginedMessage-Fallklasse Logined(val name: String) erweitert Model ( override defprocessor(): Processor = new ProcessorImpl(this) ) versiegelte abstrakte Klasse LogoutedMessage-Fallklasse Login(name: String) erweitert LogoutedMessage-Fallklasse Logouted() erweitert Model ( override def Processor(): Processor = new ProcessorImpl(this) ) object Main ( import scala.annotation.tailrec @tailrec def Process(p: Processor) ( Process(p.next()) ) def main(args: Array) = (process(new ProcessorImpl(Logouted())) ) )

Klasse ProcessorImpl(model: M)(impliziter Updater: (M, Message) => Model, view: M => View) erweitert Processor ( def next(): Processor = ( val v = view(model) val msg = v. run() val newModel = updater(model,msg) newModel.processor() ) )
Hier sehen wir neue mysteriöse Parameter (Impliziter Updater: (M, Message) => Modell, Ansicht: M => Ansicht). Das Schlüsselwort implicit bedeutet, dass der Compiler beim Aufruf dieser Funktion (genauer gesagt des Klassenkonstruktors) nach Objekten geeigneter Typen sucht, die im Kontext als implizit markiert sind, und diese als entsprechende Parameter übergibt. Dies ist ein ziemlich komplexes Konzept, dessen Anwendung die Implementierung von Typklassen ist. Hier versprechen sie dem Compiler, dass für bestimmte Implementierungen des Modells und der Nachricht alle notwendigen Funktionen von uns bereitgestellt werden. Nun lasst uns dieses Versprechen einlösen.

Objektaktualisierungsprogramme ( implicit def logoutedUpdater(model: Logouted, msg: LogoutedMessage): Model = ( (model, msg) match ( case (Logouted(), Login(name)) => Logined(name) ) ) implicit def viewLogouted(model : Logouted) = new View ( override def run() : LogoutedMessage = ( println("Enter name ") val name = scala.io.StdIn.readLine() Login(name) ) ) implicit def loginedUpdater(model: Logined, msg : LoginedMessage): Model = ( (model, msg) match ( case (Logined(name), Logout()) => Logouted() case (Logined(name), Greet()) => model ) ) implicit def viewLogined( model: Logined) = new View ( val name = model.name override def run() : LoginedMessage = ( println(s"Hello, $name") println("Leere Zeichenfolge für die Abmeldung, nonempy für die Begrüßung.") scala.io .StdIn.readLine() match ( case "" => Logout() case _ => Greet() ) ) ) import updaters._

Haskell

Datenmodell = für alle m. (Aktualisierbar m, Sichtbar m) => Modell m-Klasse Aktualisierbar m, wobei Daten Nachricht m:: * update:: m -> (Nachricht m) -> Modellklasse (Aktualisierbar m) => Sichtbar m, wobei Ansicht:: m -> (Ansicht (Nachricht m)) data Logouted = Abgemeldete Daten Logined = Angemeldete Zeichenfolge
Ich habe versucht, Updater und View so weit wie möglich zu trennen, also habe ich zwei verschiedene Typklassen erstellt, aber bisher hat es nicht gut geklappt.

Die Updater-Implementierung ist einfach

Instanz aktualisierbar abgemeldet, wo Daten abgemeldet sind Begrüßung Update m Abmelden = Modell Abgemeldet Update m Begrüßung = Modell m
Ich musste IO als View festlegen. Versuche, es abstrakter zu machen, verkomplizierten alles erheblich und erhöhten die Koppelung des Codes – der Modelltyp muss wissen, welche Ansicht wir verwenden werden.

System.IO-Typ importieren View a = IO eine Instanz Sichtbar Abgemeldet wo view Abgemeldet = do putStr "Login: " !\n" hFlush stdout l<- getLine pure $ if l == "" then Logout else Greeting
Nun, die ausführbare Umgebung unterscheidet sich kaum von der ähnlichen in Idris

RunMUV::Model -> IO a runMUV (Model m) = do msg<- view m runMUV $ update m msg main:: IO () main = runMUV (Model Logouted)