2012-09-14 22 views
10

A volte non sono sicuro di come utilizzare webapp2.redirect.webapp2 reindirizzamento spiegato

C'è sempre un momento in cui dovrei usare self.redirect("/blah") invece di return self.redirect("/blah")

Qui è la mia comprensione/ipotesi della time-line: (a volte io sono confuso circa se l'oggetto risposta fa qualcosa o se webapp2 lo fa)

  1. visito il mio sito web multithread www.mysite.com/name/robert, Chrome invia un Get richiesta (permette di assumere questa richiesta è un file di testo)
  2. webapp2 afferra questo "file di testo" e lo trasforma in una webapp2.Richiesta. webapp2 crea anche una nuova webapp2.Response.
  3. in qualche modo l'URL della richiesta viene fornito al router per la corrispondenza (sia tramite webapp2 o dalla risposta). Un RequestHandler appropriato è istanziato. Il metodo get() di RequestHandler viene chiamato con gli argomenti appropriati .
  4. durante questo periodo c'è stata solo una richiesta e una risposta .
  5. il metodo get() chiama response.out.write ("ciao mondo") aggiungendo "ciao mondo" al corpo della risposta?
  6. il metodo get() chiama self.redirect ('/ foo')
  7. Cose che succedono
  8. il metodo get() chiama self.out.write ("bye mondo")
  9. la risposta viene inviato al client contenente ciao mondo, ciò che il cibo ha aggiunto, ciao mondo

esempio della funzione iniziale get:

def get(): 
    self.write('hello world') 
    self.redirect('/foo') 
    self.write('bye world') 

Cosa succede "" "? Suppongo che il router trovi/foo/'s RequestHandler. Quali modifiche vengono apportate alla richiesta e alla risposta prima di foo's requestHandlers get() il metodo è chiamato. La richiesta viene cancellata e sostituita da una nuova richiesta GET? La risposta è stata cancellata e sostituita da una nuova? Quale contesto rimane presente nel gestore della richiesta iniziale? l'esecuzione del codice ritorna al metodo di acquisizione dei gestori di richieste iniziali e, in tal caso, il contesto che potrebbe essere stato ripristinato?

dispiace se questo è un po 'di un boccone, ho provato spiegare quello che voglio sapere :)

Forse sarebbe stato più facile chiedere alcuni casi d'uso (fare e non fare) di utilizzando invece il reindirizzamento.

risposta

10

Il metodo di reindirizzamento è in realtà solo alcuni utili fluff intorno all'impostazione dello stato di risposta e dell'intestazione di posizione della risposta. Nulla accade realmente fino a quando la risposta non viene inviata al client che segue il reindirizzamento. Dovresti restituire il risultato della chiamata al reindirizzamento semplicemente per evitare che venga eseguito più codice se ci fosse dell'altro dopo il reindirizzamento che non volevi eseguire.

La fonte è abbastanza facile da leggere .. http://webapp2.readthedocs.io/en/latest/_modules/webapp2.html#redirect

+0

Così il cliente ottiene 302 e segue il reindirizzamento. Sembra inefficiente (richiede due richieste invece di una).Se tutti vengono reindirizzati su/login, direi che la risposta restituirà il modulo di accesso e dirò che è stato reindirizzato tutto in una sola risposta, anziché in due. –

+1

solo per confermare, il metodo foos get() non viene chiamato fino a quando il browser dei client non segue il reindirizzamento con una nuova richiesta all'intestazione della nuova posizione delle risposte, il che significa che foos può anche chiamare il metodo su un server diverso. –

+1

Se si desidera un reindirizzamento interno, è possibile chiamare un altro metodo di gestione dal codice, ad esempio aggiornerò qualcosa in un gestore di post e restituirà self.get() come risposta. Il problema è che stai restituendo il contenuto da una risorsa diversa da quella richiesta dal server. Se va bene per la situazione, allora, ok. Se esegui un reindirizzamento, il browser (o lo spider) sa cosa sta ottenendo. Per quanto riguarda il reindirizzamento e la fornitura della nuova risposta, i browser non funzionano in questo modo. per confermare: sì, e perderesti "ciao mondo" e "ciao mondo" all'etere (per un utente del browser) – lecstor

Problemi correlati