Aprendendo Ruby on Rails – Aula 1

Maurício Linhares

Por que Rails? }  Escrito em Ruby (sim, isso é uma vantagem);

}  Baseado em necessidades reais, não em um comitê (JSF, estou olhando pra você);

}  Convenção e padrões em vez de configuração;

}  Respostas rápidas a alterações feitas em código;

Por que Rails? }  Desenvolvido de forma aberta com uma licença

permissiva e business friendly (MIT);

}  Comunidade ativa e focada em desenvolvimento web que já produziu plugins e integrações com várias ferramentas comuns;

}  Vários livros, muita documentação disponível de forma gratuita e aparição massiva em eventos de desenvolvimento;

De onde vem o Rails? }  David Heinemeier Hanson;

}  37 Signals;

}  Basecamp;

}  Foi lançado em julho de 2004 e a equipe de desenvolvimento começou a ser formada em fevereiro de 2005;

Estrutura do framework

ActiveSupport

ActiveRecord ActionPack ActionView

ActiveSupport }  Contém classes utilitárias genéricas que são utilizadas por

todo o framework e aplicações escritas com ele;

}  Adiciona novas funcionalidades a classes padrão do Ruby, como Array e Hash;

}  É dependência obrigatória de qualquer aplicação Rails;

ActiveRecord }  Biblioteca de mapeamento objeto/relacional padrão do

Rails;

}  Faz a ponte entre o banco de dados relacional e os objetos que permeiam a aplicação;

}  Contém a implementação das Migrations que são a forma evolutiva de tratar os bancos de dados trazida pelo Rails;

ActionPack e ActionView }  Fazem a ponte entre o navegador web e o código da

aplicação;

}  O ActionPack faz a recepção e tratamento de requisições vindas dos clientes, incluindo controle de sessão e autenticação de clientes;

}  O ActionView contém as classes utilizadas para gerar saída para os clientes da aplicação web;

MVC - Arquitetura de aplicações Rails

Model - ActiveRecord

Controller - ActionController

View - ActionView

Workflow comum }  O Controler recebe uma requisição;

}  Transforma os dados da requisição e os repassa para o Model;

}  Recebe os resultados do Model e os repassa para a View;

Controller }  Rotear requisições para os componentes corretos;

}  Transformar os dados da requisição em uma forma aceitável para o modelo;

}  Chamar o modelo para executar a lógica nos dados já tratados;

}  Entregar o resultado da lógica do modelo para a camada de visualização;

Model }  O coração da aplicação, onde vive toda lógica de negócio

da mesma;

}  Pode ou não ser representado por objetos ActiveRecord e se comunicar com o banco de dados;

}  Também podem ser serviços, objetos que encapsulam uma lógica complexa de negócio ou que falam com outros sistemas;

View }  Apresenta as informações para o cliente, que pode ser

um usuário real ou ainda outro sistema;

}  Não pode conter lógica de negócio, deve apenas mostrar a informação e ter código relacionado a apresentação dos dados;

}  Deve sempre receber os dados prontos do Controller;

MVC no Rails

} app/ } controllers } helpers } models } Views } assets

Helpers? }  São objetos que servem pra ajudar a visualização a

mostrar dados para os clientes;

}  Em vez de se utilizar de tags especiais ou poluir a página HTML com código Ruby, ele deve viver nas classes Helper;

}  Devem ser utilizadas somente para código relacionado a apresentação de informação;

Criando o produto

}  rails generate migration criar_produtos

Escrevendo a migração class CriarProdutos < ActiveRecord::Migration def self.up create_table :produtos do |t| t.string :nome, :null => false t.text :descricao t.decimal :preco, :precision => 10, :scale => 2, :null => false t.timestamps end end def self.down drop_table :produtos end end

Tipos disponíveis nas migrações

Mais parâmetros em um migration }  :null – indica se pode ser null ou não (true-false)

}  :limit – indica o tamanho máximo do campo

}  :default – indica o valor padrão do campo

}  :precision – indica a precisão do número

}  :scale – indica a escala do número (quantas casas depois da vírgula)

Criando o banco e executando a migração

}  rake db:create

}  rake db:migrate

Criando o modelo em app/models/produto.rb

class Produto < ActiveRecord::Base validates_presence_of :nome, :preco validates_numericality_of :preco, :greater_than =>

0, :allow_nil => true end

ActiveRecord::Base }  Todas as classes que acessam o banco de dados devem

herdar de ActiveRecord::Base ou de um dos seus descendentes;

}  Cada uma das classes deve representar uma tabela no banco de dados;

}  Dentro dessa classe ficam definidas as validações e associações com outros objetos;

Criando o controlador – app/controllers/produtos_controller.rb class ProdutosController < ApplicationController def index @produtos = Produto.all respond_to do |format| format.html format.xml do render :xml => @produtos end end end end

Criando um controller }  Todos os controllers da aplicação devem herdar de

ApplicationController ou de um dos seus descendentes;

}  Produto.all retorna todos os objetos da tabela “produtos”;

}  Com o uso de respond_to é possível usar um mesmo código e retornar formatos diferentes;

Roteando requisições para o lugar certo – config/routes.rb

resources :produtos root :to => ’produtos#index'

Definições }  root - mapeia a rota raiz da aplicação “/” – é necessário

remover o arquivo “public/index.html”

}  match – mapeia uma URL para uma ação ou controller, aceita os parâmetros especiais: }  :controller }  :action }  :format }  Além da possibilidade de se definir os seus próprios

parâmetros }  match “produtos/:action/:id” => “produtos#:action”

map.resources – REST - Representational State Transfer

}  HTTP é um protocolo de troca de documentos ou recursos;

}  Os recursos são identificados através de URLs;

}  Uma aplicação web é um conjunto navegável de recursos;

rake:routes produtos GET /produtos(.:format)

{:action=>"index", :controller=>"produtos"} POST /produtos(.:format) {:action=>"create", :controller=>"produtos"} new_produto GET /produtos/new(.:format)

{:action=>"new", :controller=>"produtos"} edit_produto GET /produtos/:id/edit(.:format)

{:action=>"edit", :controller=>"produtos"} produto GET /produtos/:id(.:format)

{:action=>"show", :controller=>"produtos"} PUT /produtos/:id(.:format) {:action=>"update", :controller=>"produtos"} DELETE /produtos/:id(.:format) {:action=>"destroy", :controller=>"produtos“}

Os métodos HTTP mais comuns }  GET – “pegar” um documento

}  POST – enviar dados para o servidor

}  DELETE – apagar um documento no servidor

}  PUT – atualizar um documento no servidor

Idempotência }  Alguns métodos HTTP podem ser chamados várias vezes

para o mesmo recurso sem causar efeitos colaterais ou recebendo sempre a mesma resposta – GET, PUT, DELETE;

}  O Método POST não é idempotente, cada chamada vai causar um efeito diferente no servidor e as respostas não vão necessariamente ser as mesmas;

Layout base da aplicação – app/views/layouts/application.html.erb

}  É a estrutura base onde as outras páginas da aplicação vão ser inseridas;

}  Cada aplicação pode ter mais do que um arquivo de layout, o uso ou não do layout depende da configuração na hora que a página está sendo gerada;

Arquivos .html.erb }  São arquivos que vão conter marcação HTML comum e

também código Ruby;

}  Todas as variáveis de instância que estavam no controller, ficam disponíveis na página;

}  Para entrar em um bloco de código Ruby, basta fazer <% %>;

}  Para gerar texto dentro da página, basta fazer <%= %>;