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




        View -         Controller -
      ActionView     ActionController
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 <%= %>;

Curso de Ruby on Rails - Aula 01

  • 1.
    Aprendendo Ruby onRails – Aula 1 Maurício Linhares
  • 2.
    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;
  • 3.
    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;
  • 4.
    De onde vemo 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;
  • 5.
    Estrutura do framework ActiveSupport ActiveRecord ActionPack ActionView
  • 6.
    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;
  • 7.
    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;
  • 8.
    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;
  • 9.
    MVC - Arquiteturade aplicações Rails Model - ActiveRecord View - Controller - ActionView ActionController
  • 10.
    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;
  • 11.
    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;
  • 12.
    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;
  • 13.
    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;
  • 14.
    MVC no Rails } app/ } controllers } helpers } models } Views } assets
  • 15.
    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;
  • 16.
    Criando o produto }  rails generate migration criar_produtos
  • 17.
    Escrevendo a migração classCriarProdutos < 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
  • 18.
  • 19.
    Mais parâmetros emum 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)
  • 20.
    Criando o bancoe executando a migração }  rake db:create }  rake db:migrate
  • 21.
    Criando o modeloem app/models/ produto.rb class Produto < ActiveRecord::Base validates_presence_of :nome, :preco validates_numericality_of :preco, :greater_than => 0, :allow_nil => true end
  • 22.
    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;
  • 23.
    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
  • 24.
    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;
  • 25.
    Roteando requisições parao lugar certo – config/routes.rb resources :produtos root :to => ’produtos#index'
  • 26.
    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”
  • 27.
    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;
  • 28.
    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“}
  • 29.
    Os métodos HTTPmais comuns }  GET – “pegar” um documento }  POST – enviar dados para o servidor }  DELETE – apagar um documento no servidor }  PUT – atualizar um documento no servidor
  • 30.
    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;
  • 31.
    Layout base daaplicaçã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;
  • 32.
    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 <%= %>;