Tradução -Começando com o CodeIgniter parte 2

Saudações a todos!
* Como o blog está somente começando eu ainda não tenho muito o que escrever. Atualmente estou começando a brincar com o CodeIgniter e achei um tutorial introdutório bem legal sobre ele. Ele foi escrito pelo Mike e está publicado no site dele o Capsize Designs. Ele foi bem gentil e permitiu que eu o traduzisse para o português.

Bem vindos novamente. No último texto nós configuramos e rodamos uma instalação do CodeIgniter e nos familiarizamos com a estrutura e instalação. Agora, nós iremos olhar de perto como o CodeIgniter lida com o MVC, e o que MVC realmente significa.

O MVC é o princípio do CodeIgniter e da maioria dos framewroks de aplicações web (Symfony, Zend, CakePHP e até mesmo o infame Ruby on Rails). É também uma boa forma de se estruturar qualquer tipo de aplicação, e você se sentirá uma pessoa melhor por ter aprendido isso. E também é bom na cama. Continuando...

Curso rápido em PHP Orientado a Objetos
CodIgniter não vai fazer sentido a menos que você se familiarize com os conceitos básicos da programação orientada a objetos. O estilo típico de muitos programadores PHP envolve codificar de uma maneira linear (faça isso e depois faça isso ou isso). Isto serve para projetos pequenos (Digo para projetos bem pequenos), mas conforme uma aplicação cresce, ela fica confusa, feia e muito má.

Contrastando com isso, nós temos a programação orientada a objetos. CI( e MVC em geral, nós veremos isso depois), usa uma versão simplificada da POO. No nível básico, nós temos classes, objetos, e funções e métodos. Classes são o modelo geral ou estrutura de alguma coisa. Um bom exemplo de uma classe é um cão. Um cão possui quatro patas, é peludo, pode latir, etc. Um cão é uma classe.

Por seguinte nós temos objetos. Objetos são instâncias especificas de classes. Por exemplo, se "cão" é uma classe, então meu Cão Pastor Australiano chamado "Tuck" seria um objeto. É um membro especifico da classe.

Finalmente, nós temos métodos e funções. Estas são as coisas que um membro da classe pode fazer. Por exemplo, a classe cão tem uma função latir(), uma função pular(), e uma função estaDormindo(), etc. No mundo da programação, você tem que criar um novo objeto (ou instância de uma classe), geralmente (dependendo da linguagem) usando algo similar a var sparky = new Cao();, e então você pode chamar métodos no nosso cão. Em PHP, chamar funções em um objeto usa a sintaxe de flecha, então para fazer Sparky pular nós usaríamos sparky->jump();.

Esta é uma versão BEM simplificada e a definição da Wikipedia de Programação Orientada a Objetos pode ajudá-lo se você ainda estiver confuso. Contudo, é muito importante ter um entendimento básico sobre isso, porque CI depende disso, como nós veremos.

Modelos, Visualizações, Controladores, Nossa!
CodeIgniter é baseado na testada e verdadeira filosofia MVC. Basicamente, o ponto básico do MVC é que você separa o que o usuário vê(as visualizações) da lógica da aplicação (geralmente os modelos). A lógica da aplicação e a apresentação são conectados pelos controladores.

Agora, não entre em pânico! Isto é bem mais simples do que parece. E quando você tiver começado, eu te prometo que você não vai querer voltar atrás. Esta separação faz tudo mais simples, fácil de entender, e alguns podem dizer que fica mais bonito (embora eu não gostaria de ser tão nerd assim, então não vou ser). Aqui está o básico do papel de cada um destes três componentes.

NOTA: Você vai ver muitas menções sobre convenções de nomes. Convenções de nomes não são absolutamente necessárias no CI (como o são no CakePHP) mas elas são recomendadas pelo fato de que se você sempre segue as mesmas orientações, você não terá que despender tempo tentando lembrar como aquela coisa era chamada. Eu tento seguir as convenções de nomes do EllisLabs, eles desenvolveram o CodeIgniter, embora você possa desenvolver suas próprias e usá-las.

Modelos
Modelos fazem qualquer coisa entre conectar-se com um banco de dados e realizarem o CRUD (Create (Criar), Read (Ler), Update (Atualizar), Delete (Excluir)). Eu gosto de ter um modelo para cada tabela do meu banco de dados, geralmente chamado "nomedatabela_model.php". Modelos (e Controladores) contem um construtor, frequentemente com o mesmo nome da página exceto que maiúsculo (se a página é chamada blog_model.php, seu construtor será chamado de Blog_model).

Relembrando nossa explanação de programação orientada a objetos, um modelo seria uma "classe". Cada modelo tem suas próprias funções (lembra disso?) que podem ser chamadas depois de você criar uma instância especifica do modelo. Acalme-se. Aqui está um exemplo.
Vamos dizer que você possui um site de E-Commerce, então você provavelmente possui um banco de dados com tabelas como produtos, usuários, compras, etc. Assim, para construir o modelo para a tabela de produtos, você criaria um arquivo chamado produtos_model.php, e o estruturaria assim:

class Produtos_model extends Model {
function Produtos_model() {
parent::Model();
}
function algumacoisa1()
{
.....faz alguma coisa....
}
function algumacoisa2()
{
.....faz alguma coisa....
}


Então basicamente, você tem um modelo com o mesmo nome da página php, e a primeira função é o construtor, que tem o mesmo nome do modelo. O construtor diz ao CI que o pai da classe é classe genérica de modelo(Model). Depois disso, você coloca algumas funções que relacionam o banco de dados e os produtos. Você pode ter uma função getPreco() ou excluiProduto(). Estas funções criam um mini-biblioteca de coisas que seu controlador pode fazer, mas o controlador em si não tem que se preocupar em como elas são feitas. Nós entusiastas da programação gostamos de chamar isso de "abstração". Ohhhhhhh...

Vale lembra que o CI não OBRIGA você a usar modelos. Você pode colocar toda a interação com o banco de dados no controlador se você quiser. Faça um favor a você mesmo e use os modelos. Conforme sua aplicação cresce, você ficará feliz de ter uma camada extra de separação para mantê-lo são.

Controladores
Controladores são pontes entre a lógica de aplicação e a visualização. No exemplo prévio do E-Commerce, o modelo Produtos_model tinha funções que faziam as operações CRUD para nós, e nosso controlador chamará estas operações para fazer o que tiver para fazer, e retornará o que tiver para ser mostrado na visualização. Na minha opinião, controladores são a beleza de frameworks MVC como o CI. Você tem a parte de banco de dados no modelo, a parte visual nas visualizações, e o meio disso nos controladores. Ele é o atravessador. Isso não faz vocês ficarem entusiasmados? Somente eu? Não minta.

A anatomia de um controlador é muito parecida com um modelo. O nome de seu controlador será todo minúsculo, e deve explicar o que ele está manipulando. Por exemplo, nós provavelmente faríamos um controlador produtos.php comunicar nosso produtos_model.php com as visualizações. Bem chame ele de produtos.php, e ele vai ficar mais ou menos assim:

class Produtos extends Controller {
function Produtos() {
parent::Controller();
}
function index() {
echo 'Olá mundo!'
}
}

NOTA: As funções nos controladores são muito legais no CI. Ao invés de ter uma página php separada para cada página no site, você pode ter um controlador para cada seção, e páginas dentro de cada seção possuem sua própria função no controlador. Isto significa que por padrão, quando você navega para um controlador (como www.seusite.com/index.php/produtos), a função index do controlador produtos será chamada. Contudo, se você quer uma página para mostrar todos os sapatos ou outra coisa, você criaria uma função "sapatos()", e então navegaria para www.seusite.com/index.php/produtos/sapatos para executar a função. Isto é incrível.

Mas este era um controlador bem simples. Frequentemente, um controlador irá criar uma instância de um modelo, chamar algumas funções do modelo, e então passar os resultados para a visualização para mostrá-las no browser. Ficará mais ou menos assim:

class Produtos extends Controller {
function list() {
$this->load->model('Productos_model');
$data['preco'] = $this->Produtos_model->getProdutoPreco(algum_parametro);
$this->load->view('produtos_view', $data);
}
}

Acostume-se BEM com a sintaxe dos comandos load ($this->load->algo). Seu controlador usa este comando para criar uma nova instância do modelo ou para passar dados para a view para serem mostrador no browser. Neste caso, nós estamos dizendo o CI que nós iremos conversar com o Produtos_model usando o comando load. Então, nós chamamos a função getProdutoPreco() do Produtos_model e passamos os resultados em um array associativo chamado $data. Nós vamos chamar nosso resultado 'preco', então nós colocamos isso como $data['preco'].

O array $data é muito importante porque é que usamos para passar informações para nossa visualização.
E falando de visualizações...

Visualizações
Visualizações mostram tudo o que o usuário vê. Existem infinitas maneiras de organizar visualizações. Algumas aplicações podem ser pequenas o bastante para ter somente uma visualização, e esta representar diferentes páginas baseada em diferentes informações que os controladores passam para ela. Você pode também ter uma visualização diferente para cada página. Você escolhe, e isto depende do quão complexas suas páginas serão.
Visualizações obviamente vão dentro da pasta de visualizações, e eu usualmente as nomeio como algumacoisa_view.php. Se sua visualização vai mostrar uma lista de produtos, porque o nome não pode ser produtos_view.php. Note que os modelos são nomeados como algumacoisa_model.php e visualizações como algumacoisa_view.php enquanto controladores são somente algumacoisa.php. Isto é porque o nome do controlador é o que aparece na url, e você quer deixá-la bonita. Sim, eu sei, você pode mudar o que aparece na URL para qualquer coisa que você queira no arquivo routes.php, mas como nós estamos no básico, não vou tentar confundi-lo com isso.

Basicamente, uma visualização é muito parecida com uma página html que vocês estão acostumados, possui um DocType, tags, head e body, etc. De fato, é bem comum ter uma visualização cabeçalho e uma visualização rodapé para carregar antes de depois do conteúdo da visualização que você estiver usando.

A parte legal: A visualização mostra informação passada a ela pelo controlador. Qualquer coisa dentro do array $data (no nosso exemplo do controlador, 'preco') será passado a visualização e nós podemos referenciar isso usando o nome do objeto como variável. Isto não é tão confuso quanto parece! Digamos que passamos $data['preco'] para a visualização. Na visualização, nós podemos referenciar isso usando $preco. Se tivéssemos passsado $data['descricao'], nós poderíamos referenciar isso como $descricao. Isto é a beleza disso tudo. Nós podemos até mesmo passar outros arrays para $data. Digamos que o array $data contenha um array chamado 'produtoinfo'. Na visualização, nós poderíamos fazer algo como $produtoinfo['preco'] ou $produtoinfo['entrega'] ou qualquer outra coisa. Oportunidades ilimitadas! EBAAAA! Você pode não estar excitado como eu estou, mas você ficará depois que entender tudo.

Para demonstrar, aqui está uma visualização bem simples que mostra o preço que passamos:


"O preço é: =$preco *



Legal e simples. Note a sintaxe alternativa PHP. Ao invés de usar um comando echo para mandar o preco, nós usamos...

=algumca_coisa_para_mostrar *

... e o "=" fez isso para você. Somente um atalho. Embora, embora como cheekygeek observou nos comentários abaixo (link para o original no inicio do texto), isto requer que as tags curtas (short tags) estejam habilitadas no php.ini. Se isto não funcionar para você, isto deve ser o motivo. Contudo, em system/application/config.php no final do arquivo, você pode mudar $config['rewrite_short_tags'] = TRUE; e o CodeIgniter vai re-escrever todas elas em tempo de execução, então elas ainda vão funcionar no seu servidor.

Bem é o bastante por agora. Espero que você tenha aprendido algo, e volte para ver a parte três! Feliz codificação!

* Eu não sei porque mas o Blogger não está aceitando as tags php. Vou tentar colocar estes códigos nos comentários.