Ciao. Ora, parleremo
dell'altra metà dei punti di vista, i modelli.
Quindi i modelli sono il nostro modo di creare HTML, e ancora,
solo per mettere a terra tutto ciò che
abbiamo qui, siamo nelle viste,
e le viste sono davvero una specie di codice,
il codice Python che guidiamo.
Tra un po' arriveremo alle forme.
Ma le viste tipo di unire le cose dai modelli,
unire le cose dai modelli,
inviare le cose e creare pagine.
Quindi questo assomiglierà molto all'HTML.
Non deve essere HTML,
può essere cose
diverse dall'HTML.
Ma i modelli nella nostra classe
saranno per lo più HTML.
Quindi sono l'ultimo piccolo pezzo
del puzzle per iniziare a costruire interfacce utente,
e da questo punto in poi,
faremo interfacce utente piuttosto che
introdurre le parti di
un'applicazione Django che hanno l'interfaccia utente.
Quindi questo è il testo dal sito web di Django.
Si tratta di modi convenienti per generare HTML in modo dinamico
e ci sono un paio di diversi motori di template.
Stiamo usando quello predefinito
e ci sono alcuni dati che passiamo nel modello.
C' è un processo che si chiama rendering.
E poi otteniamo l'HTML e
torniamo al browser con quella risposta HTTP,
che abbiamo già fatto.
Il ciclo richiesta-risposta è lo stesso.
La differenza è che invece di scrivere
codice Python per concatenare un sacco di cose insieme,
useremo un motore di template.
Quindi questo è il tipo di cose che
abbiamo fatto fin dall'inizio.
Abbiamo una classe in una vista,
una classe di visualizzazione RestMainView che estende questa vista.
In arriva forse l'oggetto richiesta e poi forse
anche un altro parametro, che non sta cambiando.
Quello che stiamo facendo qui è usare la concatenazione.
Concatenazione, questi piccoli segni più, scappando,
stiamo facendo tutta la fuga e la concatenazione,
e poi rimandiamo indietro una risposta.
Quindi ciò che torna indietro è una risposta. Quindi quello che arriva è una richiesta,
quello che torna indietro è una risposta.
Lo faremo ancora. Ci
sbarazzeremo di quella parte centrale, la
renderemo un po' piu' bella,
e renderemo piu' sensata.
Se lo guardi,
devi farlo sintatticamente bene.
Hai problemi di indentazione,
tre righe di Python,
sto usando le virgolette triple,
sto usando plus, devo ottenere tutte quelle corrispondenze insieme,
e poi come alla fine
l'HTML sta tornando indietro. Userò virgolette singole
e doppie virgolette e tutti questi tipi di cose,
e JavaScript sembrerà davvero brutto qui. Il
rientro del
tipo HTML di combatterà con il rientro del Python.
Voglio dire, ne ho fatte solo brevi,
perche' volevo mostrarti un po'
prima che ti mostrassimo dei modelli.
Quindi il processo di base è questo bit di software,
un software modello che Django ci fornisce.
Stiamo usando il Django integrato, e fondamentalmente, il
modello è un HTML con alcuni hotspot che dice
«metti i dati qui», e quindi il resto è solo HTML.
E poi passiamo i dati
in una sorta di oggetto, un dizionario, ecc
E poi un po 'di codice tira tutta quella roba insieme
e poi produce l'HTML
con tutti i dati inseriti in esso.
Spesso i dati di rendering che stiamo
passando provengono da un modello, ad esempio.
Potremmo parlare con un database,
caricare un mucchio di righe
e poi inserirlo.
Ma nella forma più semplice, quello che abbiamo è che
abbiamo come un piccolo dizionario,
chiamiamo questo il contesto,
si potrebbe chiamare i dati di rendering,
e poi si ha il modello di rendering.
Quindi il modello di rendering è in realtà HTML,
ed è questo che rende molto più facile da
guardare perché non stai
mettendo virgolette doppie intorno a nulla,
non c'è concatenazione, ma
ci sono caratteri speciali.
E ciò che la doppia parentesi graffa
che circonda dice è, invece di questo,
tira fuori questo bit e sostituiscilo con
qualunque cosa sia nella variabile dat dai dati renderizzati.
E così è così che quando è tutto detto e fatto,
questo viene sostituito e il Fun Stuff sostituisce il tutore
riccio, il tutore riccio dat nell'output finale.
E se ci hai pensato per un po',
probabilmente potresti scrivere un motore di rendering,
non sono così difficili.
Ora, vedrai che hanno
alcune funzionalità sofisticate alla fine,
quindi probabilmente non vuoi
scrivere il tuo motore di rendering,
ma potresti immaginare un incarico Python in cui dico,
scrivimi una funzione che prende
un dizionario che assomiglia a questo,
sai, chiave-valore dat Roba divertente.
E poi prendi un file di testo che ha una parentesi graffa, una
parentesi graffa, dat, una parentesi graffa
, e poi trova
che e poi sostituiscilo con quella stringa.
Potresti scrivere quel codice.
Non vuoi scrivere quel codice.
Django ha già scritto quel codice per te.
Quindi ecco il codice in azione.
Quindi chiameremo questo.
Siamo nell'applicazione chiamata t-m-p-l, tmpl.
Quindi abbiamo l'applicazione tmpl,
abbiamo il gioco vista,
e poi abbiamo un numero 200,
e questo è quello che abbiamo messo nel nostro urls.py per
instradare la vista del gioco e prendere un parametro.
Ricordate che le lumache sono
una versione speciale di stringhe che sono lettere
, numeri e trattini, credo.
E così l'intera richiesta proveniente dal browser
sta entrando nella richiesta variabile.
Questo numero 200 sta arrivando
nella variabile dall'URL,
sta arrivando nella supposizione variabile.
E così invece di concatenare insieme,
creeremo un contesto,
quello che chiamo un contesto, che è solo
un dizionario di coppie chiave-valore
e la chiave per indovinare è g-u-e-s-s, è una stringa.
Questa ipotesi sarà importante all'interno del modello.
E poi tiriamo questo numero 200
e lo convertiamo
in un intero, e poi lo passiamo.
E questo rendering, lo passiamo l'oggetto richiesta,
lo passiamo il nome di un modello,
e poi passiamo il contesto,
le coppie chiave-valore da sostituire in quello.
Quindi diamo un'occhiata.
Quindi, se guardiamo a questo modello,
ha una serie di parentesi graffe come hotspot,
luoghi in cui si dovrebbe sostituire roba.
E così la doppia parentesi graffa dice solo
recuperare la stringa che è sotto indovinare e inserirla,
ed è così che otteniamo La tua ipotesi era
200 nell'output finale.
E poi abbiamo la percentuale di parentesi graffe
fino alla percentuale di parentesi
graffe, e questa è una serie di if-then-elses.
Quindi puoi mettere la logica anche qui.
Non devi prendere questa corda e metterla dentro.
Quindi quello che stiamo facendo è fondamentalmente
dire che se l'ipotesi è inferiore a 42,
stampiamo troppo basso,
se è superiore a 42,
stampiamo Troppo alto, e naturalmente
se è 42, stampiamo appena giusto.
E dato che la nostra ipotesi era di 200,
stampa «Troppo alto».
E quindi fondamentalmente, questo rende questo codice di visualizzazione
molto più semplice e non mette meno thans,
e più grandi thans e concatenazioni.
È tutto sostituito da questa routine di rendering.
Ora, la routine di rendering restituisce una richiesta di risposta HTTP.
Quindi, quando lo riprendiamo, lo restituiamo e basta.
Quindi restituiamo a Django
la richiesta di risposta HTTP,
e quindi la pagina viene visualizzata nel nostro browser.
Ricorda che abbiamo un progetto Django,
e questo è il progetto Django.
Nel mio caso, il progetto Django è dj4e-samples,
e ho un sacco di piccole applicazioni,
tutte queste cose, in effetti,
tmpl è quello a cui stiamo lavorando in questo momento.
Questi sono solo i diversi pezzi di
codice sorgente di esempio che
ho costruito per questa classe di cui parlare.
E quindi quelle sono applicazioni.
Quindi è solo quella terminologia Django,
progetto composto da una o più applicazioni in cartelle. Ok?
E così il problema è che questi modelli,
quando Django si avvia basato su settings.py,
carica tutti questi file,
li carica tutti.
Quindi li carica tutti
e i modelli sono in realtà globali,
e lo vedremo in un po ',
sono globali in tutte le applicazioni.
E quindi il problema è che se hai
un nome di modello come
detail.html e hai
un sacco di applicazioni come faccio io,
tutte che vogliono avere un modello chiamato detail.html,
non funziona perché
quale dei, ci sarebbe modello/dettaglio in due cartelle,
è Non è chiaro di quale stai parlando.
Quindi abbiamo adottato una convenzione che prendiamo
il nome dell'applicazione e facciamo
una sottocartella all'interno di modelli
che è il nome dell'applicazione,
e quindi usiamo questo
favs/detail.html o pics/detail.html come
nome del modello.
Quindi, in un certo senso, stiamo introducendo una sottocartella.
All' inizio e' un po' scottante
perche' vedi che e' la stessa cosa.
E' un buon convegno.
È un peccato che dobbiamo avere la convenzione,
ma poiché questi nomi finiscono per essere globali nell'
intero progetto Django in ogni applicazione
e per ottenerli correttamente nominati,
è necessario introdurre
questo livello extra di reindirizzamento.
Con gli accessi, ci sono
modelli che sono memorizzati all'esterno in altre applicazioni.
Quindi a volte vuoi ottenere
un modello in qualche altra applicazione.
Quindi ci sono tutti i tipi di motivi per cui questa è una grande idea.
E' solo che non e' la cosa piu' bella del mondo.
Quindi, quando lo vedi, non dare di matto.
Provo a chiamarlo nelle diapositive.
E così abbiamo messo questi percorsi
che includono il nome dell'applicazione due volte.
È strano, ma è
necessario farlo a causa dell'idea
che tutti questi nomi di modelli
siano globali nell'intera applicazione.
Ma se poi chiamiamo questo il nome del modello
con il nome dell'applicazione prefissato, va via.
Django avrebbe potuto renderlo un po 'più facile per noi,
ma fondamentalmente no,
e quindi dobbiamo farlo,
ma tutti lo fanno allo stesso modo.
Quindi ora quello di cui voglio parlare
è il vero linguaggio di template stesso.
Ti ho mostrato un paio di esempi,
le doppie parentesi graffe.
Ma si scopre che ci sono
molte cose che puoi fare con le
doppie parentesi graffe nel linguaggio del modello.
[ MUSIC]