Quando você está escrevendo seus próprios programas do começo ao fim, é fácil ver controle de fluxo. O programa começa aqui, há um loop lá, chamadas de método estão aqui, tudo é visível. Mas em uma aplicação Rails, as coisas não são tão simples. Com uma estrutura de qualquer tipo, você renuncia ao controle de coisas como "fluxo" em favor de uma maneira mais rápida ou mais simples de executar tarefas complexas. No caso do Ruby on Rails, o controle de fluxo é tratado nos bastidores e tudo o que resta é (mais ou menos) uma coleção de modelos, visualizações e controladores.
No centro de qualquer aplicativo da web está o HTTP. HTTP é o protocolo de rede que seu navegador usa para conversar com um servidor web. É daí que vêm termos como "request", "GET" e "POST", que são o vocabulário básico deste protocolo. No entanto, como o Rails é uma abstração disso, não gastaremos muito tempo conversando sobre isso.
Quando você abre uma página da Web, clica em um link ou envia um formulário em um navegador da Web, o navegador se conecta a um servidor da Web via TCP / IP. O navegador envia ao servidor uma "solicitação", pense nele como um formulário de correio que o navegador preenche solicitando informações em uma determinada página. O servidor finalmente envia ao navegador uma "resposta". O Ruby on Rails não é o servidor da web, o servidor web pode ser qualquer coisa da Webrick (o que geralmente acontece quando você inicia um servidor Rails a partir de a
linha de comando) ao Apache HTTPD (o servidor da web que alimenta a maior parte da web). O servidor da Web é apenas um facilitador, pega a solicitação e a entrega ao seu aplicativo Rails, que gera a resposta e passa volta ao servidor, que por sua vez o envia de volta ao cliente. Portanto, o fluxo até agora é:Uma das primeiras coisas que um aplicativo Rails faz com uma solicitação é enviá-lo pelo roteador. Toda solicitação tem uma URL, é isso que aparece na barra de endereço de um navegador da web. O roteador é o que determina o que deve ser feito com essa URL, se a URL fizer sentido e se a URL contiver algum parâmetro. O roteador está configurado em config / routes.rb.
Primeiro, saiba que o objetivo final do roteador é combinar uma URL com um controlador e uma ação (mais sobre isso posteriormente). E como a maioria dos aplicativos Rails é RESTful e as coisas nos aplicativos RESTful são representadas usando recursos, você verá linhas como recursos: posts em aplicações típicas do Rails. Isso corresponde a URLs como /posts/7/edit com o controlador Posts, o editar ação na postagem com o ID 7. O roteador apenas decide para onde as solicitações vão. Portanto, nosso bloco [Rails] pode ser expandido um pouco.
Agora que o roteador decidiu para qual controlador enviar a solicitação e para qual ação nesse controlador, ele a envia. Um Controller é um grupo de ações relacionadas, agrupadas em uma classe. Por exemplo, em um blog, todo o código para visualizar, criar, atualizar e excluir postagens do blog é agrupado em um controlador chamado "Post". As ações são normais métodos desta classe. Os controladores estão localizados em app / controllers.
Então, digamos que o navegador da web enviou uma solicitação para /posts/42. O roteador decide que isso se refere ao Postar controlador, o mostrar método e o ID da postagem a ser exibida é 42, então chama o mostrar método com este parâmetro. o mostrar O método não é responsável por usar o modelo para recuperar os dados e usar a visualização para criar a saída. Então, nosso bloco [Rails] expandido é agora:
O modelo é o mais simples de entender e mais difícil de implementar. O Modelo é responsável por interagir com o banco de dados. A maneira mais simples de explicar isso é o modelo é um conjunto simples de chamadas de método que retornam objetos Ruby simples que lidam com todas as interações (leituras e gravações) do banco de dados. Portanto, seguindo o exemplo do blog, a API que o controlador usará para recuperar dados usando o modelo será semelhante a Post.find (params [: id]). o params é o que o roteador analisou a partir da URL, Post é o modelo. Isso faz consultas SQL ou faz o que for necessário para recuperar a postagem do blog. Os modelos estão localizados em aplicação / modelos.
É importante observar que nem todas as ações precisam usar um modelo. A interação com o modelo é necessária apenas quando os dados precisam ser carregados do banco de dados ou salvos no banco de dados. Como tal, colocaremos um ponto de interrogação depois em nosso pequeno fluxograma.
Finalmente, é hora de começar a gerar um pouco de HTML. O HTML não é tratado pelo próprio controlador, nem pelo modelo. O objetivo de usar uma estrutura MVC é compartimentar tudo. As operações do banco de dados permanecem no modo, a geração HTML permanece na visualização e o controlador (chamado pelo roteador) chama os dois.
Normalmente, o HTML é gerado usando Ruby incorporado. Se você conhece o PHP, ou seja, um arquivo HTML com código PHP incorporado, o Ruby incorporado será muito familiar. Essas visualizações estão localizadas em aplicativo / visualizações, e um controlador chamará um deles para gerar a saída e enviá-la de volta ao servidor da web. Quaisquer dados recuperados pelo controlador usando o modelo geralmente serão armazenados em um variável de instância que, graças a alguma mágica do Ruby, estará disponível como variáveis de instância na exibição. Além disso, o Ruby incorporado não precisa gerar HTML, pode gerar qualquer tipo de texto. Você verá isso ao gerar XML para RSS, JSON etc.
Essa saída é enviada de volta ao servidor da Web, que a envia de volta ao navegador da Web, que conclui o processo.