Criando uma aplicação Rails (parte 2)

Vamos conhecer a anatomia de uma aplicação Rails recém criada antes de começar a criar nosso código.

Anatomia de uma aplicação Rails

Nosso objetivo agora é conhecer de forma simples e direta o que representam as pastas e arquivos gerados pelo Rails. Vamos acessar então a pasta da nossa aplicação Done:

cd ~/workspace/done

E listar seus arquivos pelo terminal ou abrindo algum editor (neste tutorial vamos usar o Atom):

 atom .

app

Esta é a principal pasta de nossa aplicação. Nela temos as pastas assets, controllers, helpers, mailers, models e views. Por enquanto não vamos tratar de helpers nem mailers.

assets

Arquivos CSS, Javascript e imagens devem ser colocadas no diretório assets para tirarmos vantagem de vários recursos que o Rails oferece como compactação e cache.

controllers, models e views

Ou Models, Views e Controllers :)

Essas pastas servem para organizarmos boa parte do código Ruby e HTML que iremos escrever.

Vamos falar muito sobre esses três, mas para você já começar a se ambientar, vamos exemplificar dentro da nossa aplicação de controle de tarefas:

  • Tarefa é a entidade que iremos abordar em nosso projeto. Seu código estará no diretório Model.
  • Para os usuários visualizarem dados das tarefas, criaremos páginas HTML dentro da pasta Views.
  • Por último precisaremos receber comandos do browser do usuário e executar ações em nossas tarefas. Para isso criaremos controllers no diretório Controllers.

helpers

Helpers são classes que injetam código direto em nossas views. Os helpers vão nos ajudar a evitar que as views tenham muito código para controle de estruturas.

mailers

Aqui vamos colocar código relacionado ao disparo de emails em nossa aplicação.

bin

Esta pasta contém alguns executáveis disponíveis para nossa aplicação. Entre eles alguns wrappers para gems executáveis como bundler e a própria gem do rails.

config

Aqui vão arquivos de configuração e código necessário para inicializar nossa aplicação.

Nesta pasta podemos destacar o arquivo routes.rb. Ele define as rotas de nossa aplicação e vamos editá-lo em breve.

Por aqui você também vai encontrar as configurações de acesso a banco (database.yml) e a pasta initializers que possui código que é executado automaticamente durante a inicialização da aplicação.

Gemfile

Se você teve problemas para incializar a aplicação no Tutorial anterior já conheceu o Gemfile.

Resumindo, o Gemfile declara todas as Gems necessárias para o funcionamento da aplicação. Sempre que precisarmos adicionar uma nova Gem vamos voltar aqui :)

db

Advinhe? Essa é a pasta com informações sobre nossa base de dados. Lembre-se que a configuração de acesso está no diretório config.

Por aqui você vai encontrar os arquivos schema.rb - responsável pela gestão do modelo da nossa base de dados e seeds.rb - onde podemos criar dados que são inseridos automaticamente em nossa base.

lib

Este é outro diretório onde podemos colocar código da nossa aplicação. Mas qual a diferença para a pasta app? Uma abordagem interessante é: todo código da aplicação que não é específico do domínio que estamos criando.

log

Arquivos de log gerados pela aplicação vem para este diretório por padrão.

public

Em versões antigas do Rails este diretório era usado para armazenar arquivos como CSS, Javascripts e imagens. Nas versões mais recentes só ficam aqui arquivos que queremos servir de forma estática.

Entre os principais podemos citar: favicon.ico, robots.txt e páginas que são exibidas em casos de erros (de acordo com o HTTP Status) como 404.html e 500.html.

test

Não existe software sem bugs. Para evitarmos problemas e garantir um bom design de nosso projeto vamos recorrer a testes que serão armazenados aqui.

É isso! Espero que agora você já se sinta mais confortável ao navegar por um projeto Rails.

vendor

Códigos de terceiros serão 'empacotados' nesta pasta quando sua aplicação for publicada.

Faça login para comentar.

Entrar

1 Comentário

Ale Galliard

Ale Galliard há aproximadamente 1 ano

Que tipo de "códigos de terceiros" são colocados na vendor? Algum framework para o front-end? Alguma estrutura em Ruby que não seja um gem ou algo do tipo? Não entendi.