Naršyklėje atidarykite http://127.0.0.1:8000/account/login/. Turėtumėte pamatyti prisijungimo puslapį. Įveskite galiojantį vartotojo vardą ir slaptažodį. Pamatysite:

Matote, kad skyrius Mano prietaisų skydelis paryškintas CSS, nes joje yra klasė pasirinktas. Kadangi vartotojas buvo autentifikuotas, vartotojo vardas rodomas dešinėje antraštės pusėje. Spustelėkite nuorodą Atsijungti. Pamatysite šį puslapį:

Šiame puslapyje matote, kad vartotojas yra atsijungęs, todėl svetainės meniu neberodomas. Dabar rodoma nuoroda dešinėje antraštės pusėje Prisijungti.

Jei matote atsijungimo puslapį iš Django administratoriaus svetainės, o ne savo atsijungimo puslapį, patikrinkite INSTALLED_APPS nustatymus ir įsitikinkite, kad django.contrib.admin yra po sąskaitą. Abu šablonai yra tame pačiame santykiniame kelyje, o „Django“ šablonų įkroviklis naudos pirmąjį rastą.

Daugiausia skirta vartotojo sąsajoms kurti. Norėdami jį naudoti, turite sukurti modelio tipą, kuris atspindi visą programos būseną, pranešimo tipą, apibūdinantį išorinius aplinkos įvykius, į kuriuos programa turi reaguoti pakeisdama savo būseną, atnaujinimo funkciją, kuri sukuria naują programos būseną. iš senos būsenos ir pranešimo bei peržiūros funkcija, kuri Remdamasi programos būsena apskaičiuoja reikiamus poveikius išorinei aplinkai, generuojančius Pranešimo tipo įvykius. Šablonas labai patogus, tačiau turi nedidelį trūkumą – neleidžia apibūdinti, kurie įvykiai yra prasmingi konkrečioms programos būsenoms.

Panaši problema iškyla (ir išsprendžiama) naudojant būsenos OO šabloną.

Elm kalba yra paprasta, bet labai griežta – ji patikrina, ar atnaujinimo funkcija kažkaip tvarko visus įmanomus modelio būsenos ir pranešimo įvykių derinius. Todėl jūs turite parašyti papildomą, nors ir nereikšmingą kodą, kuris paprastai palieka modelį nepakitęs. Noriu parodyti, kaip to galima išvengti sudėtingesnėmis kalbomis – Idris, Scala, C++ ir Haskell.

Visas čia rodomas kodas yra prieinamas GitHub eksperimentams. Pažvelkime į įdomiausias vietas.

MUV yra konstruktorius. Jis priima parametrus: modelis - pradinė programos būsena, atnaujintojas - funkcija, skirta atnaujinti būseną įvykus išoriniam įvykiui, ir vaizdas - išorinio vaizdo kūrimo funkcija. Atkreipkite dėmesį, kad atnaujinimo ir peržiūros funkcijų tipas priklauso nuo modelio reikšmės (naudojant funkciją msg iš tipo parametrų).

Dabar pažiūrėkime, kaip paleisti šią programą

MuvRun: (Application modelType msgType IO) -> IO a muvRun (MUV modelio atnaujinimo rodinys) = do msg<- view model muvRun (MUV (updater model msg) updater view)
Kaip išorinį atvaizdavimą (vaizdą) pasirinkome įvesties/išvesties operaciją (Idris, kaip ir Haskell, įvesties/išvesties operacijos yra pirmos klasės reikšmės; kad jos būtų įvykdytos, reikia atlikti papildomus veiksmus, dažniausiai grąžinant tokią operaciją iš pagrindinės funkcijos).

Trumpai apie IO

Atliekant (IO a) tipo operaciją, atsiranda tam tikras poveikis išoriniam pasauliui, galbūt tuščias, ir programai grąžinama a tipo reikšmė, tačiau standartinės bibliotekos funkcijos suprojektuotos taip, kad ji galėtų apdorojami tik generuojant naują IO tipo reikšmę b. Taip grynos funkcijos atskiriamos nuo funkcijų, turinčių šalutinį poveikį. Tai neįprasta daugeliui programuotojų, tačiau padeda parašyti patikimesnį kodą.

Dabar apibūdinkime subjektų tipus, su kuriais ketiname dirbti

Duomenų modelis = Atsijungta | Prisijungimo eilutės duomenys MsgOuted = Prisijungimo eilutės duomenys MsgIned = Atsijungti | Sveikiname visą msgType: Modelis -> Tipas msgType Logouted = MsgOuted msgType (Prisijungta _) = MsgIned
Čia aprašome modelio tipą, atspindintį dviejų sąsajos būsenų buvimą – vartotojas nėra prisijungęs, o vartotojas, kurio vardas yra String, yra prisijungęs.

Toliau aprašome du skirtingižinučių tipai, aktualūs skirtingiems modelio variantams - jei esame atsijungę, tuomet galime prisijungti tik tam tikru vardu, o jei jau esame prisijungę, galime arba atsijungti, arba pasisveikinti. Idris yra stipriai spausdinama kalba, kuri neleis sumaišyti skirtingų tipų.

Ir galiausiai, funkcija, kuri nustato modelio reikšmės atitiktį pranešimo tipui.

Funkcija deklaruojama kaip bendra - tai yra, ji neturėtų užstrigti ar užstrigti, kompiliatorius bandys tai stebėti. msgType iškviečiamas kompiliavimo metu, o jo visuma reiškia, kad kompiliacija neužstos dėl mūsų klaidos, nors negali garantuoti, kad šios funkcijos vykdymas išeikvos sistemos išteklius.
Taip pat garantuojama, kad jis nevykdys „rm -rf /“, nes jo paraše nėra IO.

Apibūdinkime atnaujintuvą:

Visas atnaujintojas: (m:Modelis) -> (msgType m) -> Modelių atnaujintojas Atsijungtas (Prisijungimo vardas) = ​​Prisijungęs vardo atnaujinimas (Prisijungęs vardas) Atsijungti = Atsijungtas atnaujintojas (Prisijungęs vardas) Sveiki = Prisijungęs vardas
Manau, kad šios funkcijos logika aiški. Norėčiau dar kartą pažymėti visuma - tai reiškia, kad Idris kompiliatorius patikrins, ar mes įvertinome visas tipo sistemos leidžiamas alternatyvas. Elm taip pat atlieka šį patikrinimą, bet negali žinoti, kad negalime atsijungti, jei dar nesame prisijungę, ir reikės aiškiai apdoroti sąlygą

Atnaujintojo atsijungta Atsijungti = ???
Idris suras tipo neatitikimus per nereikalingą patikrinimą.

Dabar pereikime prie rodinio – kaip įprasta vartotojo sąsajoje, tai bus sunkiausia kodo dalis.

Visas prisijungimo puslapis: IO MsgOuted loginPage = do putStr "Prisijungimas: " žemėlapis Prisijungti getLine total genMsg: String -> MsgIned genMsg "" = Atsijungti genMsg _ = Sveikiname visą darbąPuslapis: String -> IO MsgIned workPage name = do putStr ("Sveiki, " ++ name ++ "\n") putStr "Įveskite tuščią eilutę atsijungimui arba netuščią pasisveikinimo eilutę\n" žemėlapis genMsg getLine bendras vaizdas: (m: Modelis) -> IO (msgType m) vaizdas Atsijungta = prisijungimas Puslapio rodinys (Prisijungęs vardas ) = darbo puslapio pavadinimas
rodinys turi sukurti I/O operaciją, kuri grąžina pranešimus, kurių tipas vėlgi priklauso nuo modelio reikšmės. Turime dvi parinktis: loginPage, kuris išspausdina pranešimą „Prisijungti:“, nuskaito klaviatūros eilutę ir įtraukia ją į prisijungimo pranešimą, ir „workPage“ su vartotojo vardo parametru, kuris atspausdina sveikinimą ir grąžina skirtingus pranešimus (bet to paties tipo). - MsgIned) priklausomai nuo to, ar vartotojas įveda tuščią ar ne tuščią eilutę. view grąžina vieną iš šių operacijų, priklausomai nuo modelio reikšmės, o kompiliatorius patikrina jų tipą, nors jis skiriasi.

Dabar galime sukurti ir paleisti savo programą

Programa: programos modelis Main.msgType IO programėlė = MUV Atsijungtas naujinimo programos vaizdas pagrindinis: IO () pagrindinis = muvRun programa
Čia reikėtų atkreipti dėmesį į subtilų dalyką – grįžta funkcija muvRun IO a, kur a nebuvo nurodyta, o reikšmė main yra tipo IO(), Kur () yra paprastai vadinamo tipo pavadinimas Vienetas, kuris turi vieną reikšmę, taip pat parašytas kaip tuščia eilutė () . Tačiau kompiliatorius gali tai lengvai susitvarkyti. vietoj to pakeiskite a().

Scala ir nuo kelio priklausomi tipai

Sealed abstract class MsgLogouted bylų klasė Prisijungimas(vardas: Eilutė) pratęsia MsgLogouted antspauduotą abstrakčią klasę MsgLogined bylų klasė Atsijungimas() išplečia MsgLogined bylų klasę Greet() išplečia MsgLogined abstrakčią klasę Rodinys ( def run() : Msg ) klasė antspauduotas ab types def view() : View ) case class Atsijungtas() extens Model ( type Message = MsgLogined override def view() : View .... ) case class Prisijungęs(vardas: String) extens Model ( type Message = MsgLogined override def view() ): Žiūrėti .... )
Scala algebriniai tipai modeliuojami paveldėjimo būdu. Tipas atitinka kai kuriuos užantspauduota abstrakčioji klasė, ir kiekvienas konstruktorius iš jo paveldėjo atvejo klasė. Bandysime juos naudoti tiksliai kaip algebrinius tipus, apibūdindami visus kintamuosius kaip priklausančius pirminiam užantspauduota abstrakčioji klasė.

Mūsų programos MsgLogined ir MsgLogouted klasės neturi bendro protėvio. Kad būtų galima pasiekti konkretaus tipo pranešimą, peržiūros funkcija turėjo būti paskirstyta skirtingose ​​modelio klasėse. Tai turi savų privalumų, kuriuos įvertins OO rėmėjai – kodas sugrupuotas pagal verslo logiką, šalia yra viskas, kas susiję su vienu naudojimo atveju. Bet aš mieliau išskirčiau požiūrį į atskirą funkciją, kurios plėtojimą būtų galima perleisti kitam žmogui.

Dabar įdiegkime atnaujinimą

Objekto naujinimo priemonė ( def update(modelis: modelis)(msg: model.Message) : Model = ( modelio atitiktis ( case Logouted() => msg match ( atvejis Prisijungimas(vardas) => Prisijungtas(vardas) ) atvejis Prisijungtas(vardas)) => msg match ( Case Logout() => Logouted() Case Greet() => model ) ) ) )
Čia mes naudojame nuo kelio priklausomus tipus, kad apibūdintume antrojo argumento tipą iš pirmojo. Kad „Scala“ priimtų tokias priklausomybes, funkcijos turi būti aprašytos suformuluota forma, ty kaip funkcija iš pirmojo argumento, kuri grąžina funkciją iš antrojo argumento. Deja, šiuo metu „Scala“ neatlieka daug tipo patikrinimų, kuriems kompiliatorius turi pakankamai informacijos.

Dabar pateikime pilną modelio įgyvendinimą ir vaizdą

Atvejo klasė Logouted() praplečia modelį ( type Message = MsgLogouted override def view() : View = new View ( override def run() = ( println("Įveskite pavadinimą ") val name = scala.io.StdIn.readLine() Prisijungimas (vardas) ) ) atvejo klasė Prisijungęs(vardas: String) pratęsia Modelį ( type Message = MsgLogined override def view() : View = new View ( override def run() = ( println(s"Hello, $name") println ( "Tuščia eilute atsijungimui, nonempy sveikinimui.") scala.io.StdIn.readLine() atitiktis ( case "" => Logout() case _ => Greet() ) ) ) abstract class View ( def run( ) ): Msg ) object Viewer ( def view(modelis: Model): View = ( model.view() ) )
Rodinio funkcijos grąžinimo tipas priklauso nuo jos argumento egzemplioriaus. Tačiau įgyvendinimui reikia modelio.

Tokiu būdu sukurta programa paleidžiama taip:

Pagrindinis objektas ( importuoti scala.annotation.tailrec @tailrec def process(m: modelis) ( val msg = Viewer.view(m).run() process(Updater.update(m)(msg)) ) def main(args: Masyvas) = ​​( procesas (atsijungta()) ) )
Taigi vykdymo sistemos kodas nieko nežino apie vidinę modelių struktūrą ir pranešimų tipus, tačiau kompiliatorius gali patikrinti, ar pranešimas atitinka dabartinį modelį.

Čia mums nereikėjo visų nuo kelio priklausomų tipų teikiamų galimybių. Įdomios savybės atsiras, jei dirbsime lygiagrečiai su keliais Model-Updater-View sistemų egzemplioriais, pavyzdžiui, kai imituosime kelių agentų pasaulį (vaizdas tada atspindėtų agento įtaką pasauliui ir grįžtamojo ryšio gavimą). Šiuo atveju kompiliatorius patikrino, ar pranešimą apdorojo būtent tas agentas, kuriam jis buvo skirtas, nepaisant to, kad visi agentai turi tą patį tipą.

C++

Algebrinius tipus galima įgyvendinti taip pat, kaip ir Scala - abstrakčioji klasė atitinka tipą, o konkretūs palikuonys atitinka algebros konstruktorius (vadinkime juos „konstruktorių klasėmis“, kad nebūtų painiojami su įprastais C++ konstruktoriais). tipo.

C++ palaiko nuo kelio priklausomus tipus, tačiau kompiliatorius negali naudoti tipo abstrakčiai, nežinodamas tikrojo tipo, su kuriuo jis susietas. Todėl su jų pagalba neįmanoma įdiegti Model-Updater-View.

Tačiau C++ turi galingą šablonų sistemą. Tipo priklausomybė nuo modelio reikšmės gali būti paslėpta specializuotos vykdomosios sistemos versijos šablono parametre.

Struct Processor ( virtual const Processor *next() const = 0; ); šabloną struct ProcessorImpl: viešasis procesorius ( const CurModel * modelis; ProcessorImpl (const CurModel* m) : modelis(m) ( ); const Procesorius *next() const ( const View * vaizdas = modelis->vaizdas(); const tipo pavadinimas CurModel::Message * msg = view->run(); ištrinti vaizdą; const Model * newModel = msg->process(modelis); ištrinti žinutę; return newModel->processor(); ) );
Aprašome abstrakčią vykdymo sistemą su vienu metodu atlikti viską, ko reikia, ir grąžinti naują vykdymo sistemą, tinkamą kitai iteracijai. Konkreti versija turi šablono parametrą ir bus specializuota kiekvienai modelio „konstruktorių klasei“. Čia svarbu, kad visos CurModel tipo savybės būtų tikrinamos šablono specializavimo metu su konkrečiu tipo parametru, o sudarant patį šabloną jų aprašyti nebūtina (nors galima naudojant sąvokas ar kitus tipų klasių įgyvendinimo būdus). „Scala“ taip pat turi gana galingą parametrizuotų tipų sistemą, tačiau ji tikrina parametrų tipų savybes, kai sudaromas parametrizuotas tipas. Ten tokio modelio įgyvendinimas yra sunkus, bet įmanomas dėl tipo klasių palaikymo.

Apibūdinkime modelį.

Struktūros modelis ( virtualus ~Model() (); virtualus const Procesorius *procesorius() const = 0; ); struct Prisijungęs: viešas Modelis ( struct Pranešimas ( const virtual Model * process(const Logined * m) const = 0; virtual ~Message() (); struct Atsijungti: viešas pranešimas ( const Model * process(const Prisijungęs * m) const; struct Sveiki: viešas pranešimas ( const Model * process(const Prisijungęs * m) const; std::string name; (...); const Žiūrėti * view() const ( grąžinti naują LoginedView(vardas); ); const Procesorius *procesorius() const ( grąžinti naują ProcessorImpl (tai); ); ); struct Atsijungta: viešas Modelis ( struct Pranešimas ( const virtual Model * process(const Atsijungtas * m) const = 0; virtualus ~ Pranešimas() (); struct Prisijungimas: viešas pranešimas ( const std::string name; Prisijungimas (std :: string lname) : name(lname) ( ); (...); const Žiūrėti * view() const ( grąžinti naują LogoutedView(); ); const Procesorius *procesorius() const ( grąžinti naują ProcessorImpl (tai); ); );
Modelio „konstruktorių klasės“ „nešasi viską su savimi“ - tai yra, jose yra joms skirtos žinutės ir peržiūros klasės, taip pat gali patys susikurti vykdomąją sistemą. Native View tipai turi bendrą visų modelių pirmtaką, kuris gali būti naudingas kuriant sudėtingesnes vykdymo sistemas. Svarbu, kad pranešimų tipai būtų visiškai izoliuoti ir neturėtų bendro protėvio.

Atnaujinimo programos įgyvendinimas yra atskiras nuo modelio, nes reikalauja, kad modelio tipas jau būtų visiškai aprašytas.

Const Model * Atsijungta::Prisijungimas::process(const Atsijungta * m) const ( ištrinti m; grąžinti naują Prisijungęs(vardas); ); const Modelis * Prisijungęs::Atsijungtas::process(const Prisijungęs * m) const ( ištrinti m; grąžinti naują Atsijungtas(); ); const Modelis * Prisijungęs::Greet::process(const Prisijungęs * m) const ( return m; );
Dabar sudėkime viską, kas susiję su vaizdu, įskaitant vidinius modelių objektus

Šablonas struct View ( virtual const Pranešimas * run() const = 0; virtualus ~View () (); ); struct Prisijungta: public Model ( struct LoginedView: public View ( const std::string name; LoginedView(std::string lname) : name(lname) (); virtual const Pranešimas * run() const ( char buf; printf("Sveiki, %s", name.c_str()) fgets(buf, 15, stdin) return (*buf == 0 || *buf == "\n" || *buf == "\r") ? (naujas Atsijungti()) : static_cast (naujas Greet); ); ); const Žiūrėti * view() const ( grąžinti naują LoginedView(vardas); ); ); struct LogoutedView: viešas vaizdas ( virtual const Pranešimas * run() const ( char buf; printf ("Prisijungti: "); fgets(buf, 15, stdin); return new Login(buf); ); ); const Žiūrėti * view() const ( grąžinti naują LogoutedView(); ); );
Ir galiausiai, parašykime pagrindinį

Int main(int argc, char ** argv) ( const Processor * p = new ProcessorImpl (naujas Atsijungtas()); while(true) (const Procesorius * pnew = p->next(); ištrinti p; p = pnew; ) grąžinti 0; )

Ir vėl Scala, šį kartą su tipo klasėmis

Panaši kodo dalis

abstract class Rodymas ( def run(): Pranešimas ) abstract class Procesorius ( def next(): Procesorius; ) antspauduota abstrakti klasė Modelis ( def processor(): Procesorius ) antspauduota abstrakčioji klasė LoginedMessage case class Atsijungti() išplečia LoginedMessage atvejo klasę Sveikin ) pratęsia PrisijungęsŽinutės atvejo klasė Prisijungtas(val pavadinimas: String) pratęsia Modelį (nepaisyti def procesorius(): Procesorius = new ProcessorImpl(this) ) užplombuota abstrakti klasė LogoutedMessage case class Prisijungimas(vardas: String) pratęsia AtsijungtaŽinutės atvejo klasė Atsijungta() išplečia 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(Atjungta())) ) )

Klasė ProcesoriusImpl(modelis: M)(numanomas atnaujinimas: (M, pranešimas) => Modelis, vaizdas: M => Rodinys) išplečia procesorių ( def next(): Procesorius = ( val v = vaizdas(modelis) val msg = v. paleisti() val newModel = atnaujintojas(modelis,msg) newModel.processor() ) )
Čia matome naujus paslaptingus parametrus (numanomas atnaujinimas: (M, pranešimas) => Modelis, vaizdas: M => Rodinys). Implicit raktažodis reiškia, kad iškviesdamas šią funkciją (tiksliau, klasės konstruktorių), kompiliatorius ieškos tinkamo tipo objektų, kontekste pažymėtų kaip implicit, ir perduos juos kaip tinkamus parametrus. Tai gana sudėtinga koncepcija, kurios viena iš programų yra tipo klasių įgyvendinimas. Čia jie kompiliatoriui pažada, kad konkretiems modelio ir pranešimo diegimams visas reikalingas funkcijas suteiksime mes. Dabar ištesėkime šį pažadą.

Objekto atnaujinimai ( implicit def logoutedUpdater(modelis: Atsijungta, msg: Atsijungta Pranešimas): Modelis = ( (modelis, msg) atitiktis ( Case (Logouted(), Prisijungimas(vardas)) => Prisijungtas(vardas) ) ) implicit def viewLogouted(modelis) : Atsijungta) = naujas Rodinys ( nepaisyti def run() : LogoutedMessage = ( println("Įveskite pavadinimą ") val name = scala.io.StdIn.readLine() Prisijungimas(vardas) ) ) implicit def loginedUpdater(modelis: Prisijungta, msg : Prisijungęs pranešimas): Modelis = ( (modelis, žinutė) atitiktis ( case (Prisijungęs(vardas), Atsijungęs()) => Atsijungtas() atvejis (Prisijungęs(vardas), Sveiki()) => modelis ) ) implicit def viewPrisijungęs( modelis: Prisijungęs) = naujas Rodinys ( val pavadinimas = model.name override def run() : LoginedMessage = ( println(s"Sveiki, $name") println("Tuščia eilute atsijungti, nonempy pasisveikinti.") scala.io .StdIn.readLine() atitikmuo ( atvejis "" => Atsijungti() atvejis _ => Sveikinimas() ) ) ) importuoti atnaujinimus._

Haskell

Duomenų modelis = visiems m. (Atnaujinama m, Matoma m) => Modelio m klasė Atnaujinama m kur duomenys Pranešimas m:: * atnaujinimas:: m -> (Pranešimas m) -> Modelio klasė (Atnaujinamas m) => Matomas m kur vaizdas:: m -> (Žiūrėti (Pranešimas m)) duomenys Atsijungti = Atsijungti duomenys Prisijungti = Prisijungta eilutė
Bandžiau kiek įmanoma atskirti atnaujinimą ir peržiūrą, todėl sukūriau dvi skirtingų tipų klases, bet iki šiol tai nepasiteisino.

Atnaujinimo diegimas yra paprastas

Egzempliorius Atnaujinamas Atsijungta, kur duomenys Žinutė Atsijungta = Prisijungimo eilutės atnaujinimas Atsijungta (Prisijungimo vardas) = ​​Modelis (Prisijungęs vardas) Atnaujinamas pavyzdys Prisijungta, kur duomenys Pranešimas Prisijungtas = Atsijungti | Pasisveikinimo atnaujinimas m Atsijungti = Modelis Atsijungtas atnaujinimas m Pasisveikinimas = Modelis m
Turėjau pataisyti IO kaip View. Bandymai jį padaryti abstrakčiau labai viską apsunkino ir padidino kodo susiejimą – Modelio tipas turi žinoti, kurį View'ą naudosime.

Importuoti System.IO tipą Žiūrėti a = IO egzempliorių Žiūrėti Atsijungta, kur vaizdas Atsijungta = do putStr "Prisijungti: " hFlush stdout fmap Prisijungti getLine egzempliorius Matomas Prisijungta, kur vaizdas (Prisijungęs vardas) = ​​do putStr $ "Sveiki " ++ vardas ++ " !\n" hFlush stdout l<- getLine pure $ if l == "" then Logout else Greeting
Na, vykdomoji aplinka mažai skiriasi nuo panašios Idris

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