Quindi ora parleremo di
una tecnica chiamata ereditarietà del modello.
E questo, e altre volte,
è un ottimo momento per rivedere la programmazione orientata agli oggetti,
perché mi piacerà usare
definizioni e parole di programmazione orientate agli oggetti
e non spiegarle completamente.
Quindi devi sapere cos'è una classe,
sai cos'è il sé,
quel genere di cose. E ho
una grande lezione online che puoi andare a leggere,
ascoltare e capire gli oggetti e
te lo spiegherò tra 30 o 40 minuti.
Quindi l'ereditarietà, in realtà da quella lezione,
è la nozione nella programmazione orientata agli oggetti
di non ripetersi.
Hai
una sorta di forma e poi fai
un gruppo di oggetti che rispecchiano quella forma,
ma puoi anche con l'ereditarietà
puoi avere una forma che crea
un'altra forma, come una forma in generale che è un triangolo.
E così si può ereditare
che tutti i triangoli hanno tutto ciò che le forme hanno e
tutti i quadrati hanno tutto ciò che le forme hanno e tutti i cerchi.
Ed è solo un modo per catturare informazioni una volta,
scrivere codice una volta, e poi non ripetere te stesso.
Le funzioni sono una forma di DRY,
non ripeterti,
i moduli lo sono, ma l'ereditarietà è la chiave.
E l'ereditarietà può intralciarci come programmatori
perché porta a codice sempre più piccolo.
Se abbiamo intenzione di fare cinque cose,
ognuna di queste cinque cose è davvero piccola perché facciamo
una cosa grande qui
e ereditiamo tutte e cinque quelle cose da esso,
ma poi lo guardi e tipo oh, io non lo capisco, giusto?
Non capisco queste solo funzioni a una riga.
Cosa stanno facendo?
Beh, la risposta e'
che ci sono 50 righe qui fuori da cui stiamo ereditando.
Quindi ne vedremo un po'.
Cercherò di alludere a quella parte in cui
guarda, c'è magia
laggiù. E molto di quello che fai in Django
è usare classi e oggetti che non hai nemmeno creato,
il che significa che hanno dati in essi
come schema dot o richiesta schema dot.
E quindi questo è solo un modo per cercare di
semplificare il modo in cui gestisci le cose,
gli oggetti che ti vengono consegnati
e poi passi gli oggetti ad altre parti di Django.
Quindi il rendering dei template dice fondamentalmente,
ok ecco alcuni dati di rendering ed ecco un modello.
Quello che succede ora è che
c'è questa cosa chiamata modello di base.
E il modello di base e il modello si combinano
insieme per essere un po 'come il modello finale,
e poi si passa
i dati di rendering e si produce l'output reso.
Diciamo solo che avevamo un mucchio di
pagine e che stavamo
facendo la stessa cosa più e più volte.
Ora lo faremo presto con la
navigazione perché vorrai mettere
un menu nella parte superiore di ogni pagina,
e letteralmente quel menu potrebbe essere 40 o 50 righe di
HTML e non vuoi ripetere
quel menu ogni volta nella parte superiore della pagina.
Quindi vuoi mettere quel posto e poi vuoi
creare molte pagine che hanno la stessa navigazione in alto, in
modo che le tue pagine mentre vai tra di
loro sembrino che la navigazione sia la stessa.
Quindi lo faremo in un modo molto, molto semplice.
Quindi abbiamo un modello,
questo cond.html con cui abbiamo giocato.
Noterai che ha un HTML e un titolo
e un tag body
e un po 'di questo, e poi ha questa roba.
Beh, diciamo che volevamo un mucchio di
pagine che contenessero tutto tranne il corpo.
Quindi quello che fondamentalmente facciamo è prendere parti di questo,
come le parti ripetute, e lo mettiamo in un modello e
poi prendiamo la parte che cambieremo
ogni volta e lo mettiamo in
un modello che poi si estende.
Quindi vedi questo qui ha una riga
che dice estende tmpl/base.html.
Quindi questo usa tutto qui dentro,
ma poi aggiunge un po' di roba, ok?
Quindi l'idea di base è dividere
questo grande modello in
parti riutilizzabili e parti non riutilizzabili.
E poi abbiamo un sacco di modelli che vengono da una base. La
chiamiamo base comunemente
nel mondo orientato agli oggetti perché è come
la cosa su cui la stiamo basando.
Quindi questa è la base e poi ci costruiremo.
Base, costruisci qualcos'altro sopra.
Quindi, come funziona in pratica,
abbiamo una visione qui.
Chiameremo questo ViewGame2, giusto?
Quindi useremo l'URL game2.
Abbiamo una vista basata sulla classe.
Abbiamo un metodo get lì dentro.
I dati della richiesta vengono forniti come richiesta.
Gli abbiamo detto di analizzare la lumaca
dalla fine e passarla a noi nell'ipotesi variabile.
Facciamo un modello, che è esattamente quello che abbiamo fatto prima,
dove abbiamo una chiave di indovinare e
il valore è l'ipotesi effettiva stessa.
E poi passiamo quel modello
nella variabile x in render,
e gli diciamo di andare a leggere tmpl/cond2,
che è la condizione del secondo condizionale
e la cosa è che
non c'è nulla nel codice Python,
nel views.py, che sappia della base.
Quello che succede è che l'unico posto in cui
si nota la base è nel modello cond2 stesso che dice,
hey vai afferrare questo e estenderlo.
Ora il modo in cui funziona è che
inizia un po 'controintuitivo.
Dice davvero di iniziare con questo modello
qui e poi spingere questo contenuto
nel modello di base e questo contenuto di
blocco e endpoint, fondamentalmente che dice cosa voglio sostituire.
Stai sostituendo i blocchi nel modello di base.
Quindi tutte le cose nel cond2.html che si trova tra
il blocco e l'endpoint sono ciò che viene poi inserito
nel modello di base. E poi in un certo senso
il modello di base, con quei blocchi
sostituiti, è ciò che viene restituito
come risultato del rendering e quindi restituito
a Django come risposta HTTP.
Li useremo molto.
Quando iniziamo a fare la navigazione,
diventeremo pazzi con queste cose.
Quindi in avanti vogliamo parlare di
mappatura URL e inversione in cui
dobbiamo effettivamente fare un link in
una pagina a una pagina diversa.
[ MUSIC]