Quando scrivi i tuoi programmi dall'inizio alla fine, è facile da vedere controllo del flusso. Il programma inizia qui, c'è un ciclo lì, le chiamate dei metodi sono qui, è tutto visibile. Ma in un'applicazione Rails, le cose non sono così semplici. Con una struttura di qualsiasi tipo, si rinuncia al controllo di cose come "flusso" a favore di un modo più rapido o più semplice per svolgere compiti complessi. Nel caso di Ruby on Rails, il controllo del flusso è tutto gestito dietro le quinte e tutto ciò che ti rimane è (più o meno) una raccolta di modelli, vista e controller.
Al centro di qualsiasi applicazione web c'è HTTP. HTTP è il protocollo di rete utilizzato dal browser Web per comunicare con un server Web. È qui che arrivano termini come "richiesta", "OTTIENI" e "POSTO", sono il vocabolario di base di questo protocollo. Tuttavia, poiché Rails è un'astrazione di questo, non passeremo molto tempo a parlarne.
Quando si apre una pagina Web, si fa clic su un collegamento o si invia un modulo in un browser Web, il browser si connetterà a un server Web tramite TCP / IP. Il browser invia quindi al server una "richiesta", pensala come un modulo di posta elettronica che il browser compila chiedendo informazioni su una determinata pagina. Alla fine il server invia una "risposta" al browser web. Ruby on Rails non è il web server però, il web server può essere qualsiasi cosa da Webrick (cosa succede di solito quando si avvia un server Rails da il
riga di comando) ad Apache HTTPD (il server Web che alimenta la maggior parte del Web). Il web server è solo un facilitatore, accetta la richiesta e la passa all'applicazione Rails, che genera la risposta e passa è di nuovo al server, che a sua volta lo rimanda al cliente. Quindi il flusso finora è:Una delle prime cose che un'applicazione Rails fa con una richiesta è inviarla tramite il router. Ogni richiesta ha un URL, questo è ciò che appare nella barra degli indirizzi di un browser web. Il router è ciò che determina cosa deve essere fatto con quell'URL, se l'URL ha un senso e se l'URL contiene parametri. Il router è configurato in config / routes.rb.
Innanzitutto, sappi che l'obiettivo finale del router è quello di abbinare un URL a un controller e un'azione (ne parleremo più avanti). E poiché la maggior parte delle applicazioni Rails sono RESTful e le cose nelle applicazioni RESTful sono rappresentate usando le risorse, vedrai delle linee simili risorse: messaggi nelle tipiche applicazioni Rails. Questo corrisponde a URL come /posts/7/edit con il controller Post, il modificare azione sulla Posta con ID 7. Il router decide semplicemente dove vanno le richieste. Quindi il nostro blocco [Rails] può essere ampliato un po '.
Ora che il router ha deciso a quale controller inviare la richiesta e a quale azione su quel controller, la invia. Un controller è un gruppo di azioni correlate raggruppate tutte insieme in una classe. Ad esempio, in un blog, tutto il codice per visualizzare, creare, aggiornare ed eliminare i post del blog è raggruppato in un controller chiamato "Post". Le azioni sono semplicemente normali metodi di questa classe. I controller si trovano in app / controller.
Supponiamo quindi che il browser web abbia inviato una richiesta per /posts/42. Il router decide che questo si riferisce al Inviare controller, il mostrare è il metodo e l'ID del post da mostrare 42, quindi chiama il mostrare metodo con questo parametro. Il mostrare Il metodo non è responsabile dell'utilizzo del modello per recuperare i dati e dell'utilizzo della vista per creare l'output. Quindi il nostro blocco espanso [Rails] è ora:
Il modello è sia il più semplice da capire che il più difficile da implementare. Il modello è responsabile per l'interazione con il database. Il modo più semplice per spiegarlo è che il modello è un semplice insieme di chiamate di metodo che restituiscono semplici oggetti Ruby che gestiscono tutte le interazioni (letture e scritture) dal database. Quindi, seguendo l'esempio del blog, l'API che il controller utilizzerà per recuperare i dati utilizzando il modello avrà un aspetto simile Post.find (params [: id]). Il params è ciò che il router ha analizzato dall'URL, Post è il modello. Questo fa query SQL o fa tutto il necessario per recuperare il post sul blog. I modelli si trovano in app / modelli.
È importante notare che non tutte le azioni devono utilizzare un modello. L'interazione con il modello è necessaria solo quando i dati devono essere caricati dal database o salvati nel database. Pertanto, inseriremo un punto interrogativo nel nostro piccolo diagramma di flusso.
Infine, è tempo di iniziare a generare un po 'di HTML. L'HTML non è gestito dal controller stesso, né è gestito dal modello. Il punto di usare un framework MVC è compartimentare tutto. Le operazioni del database rimangono nella modalità, la generazione HTML rimane nella vista e il controller (chiamato dal router) le chiama entrambe.
L'HTML viene normalmente generato utilizzando Ruby incorporato. Se hai familiarità con PHP, vale a dire un file HTML con codice PHP incorporato, allora Ruby incorporato sarà molto familiare. Queste viste si trovano in app / viewse un controller chiamerà uno di essi per generare l'output e inviarlo al server Web. Tutti i dati recuperati dal controller utilizzando il modello verranno generalmente archiviati in un variabile di istanza che, grazie ad un po 'di magia Ruby, sarà disponibile come variabile di istanza all'interno della vista. Inoltre, Ruby incorporato non ha bisogno di generare HTML, può generare qualsiasi tipo di testo. Lo vedrai quando generi XML per RSS, JSON, ecc.
Questo output viene inviato al server Web, che lo invia al browser Web, che completa il processo.