Controllers no CodeIgniter

Como pudemos conferir no artigo sobre MVC, Controllers são responsáveis por controlar o fluxo dos programas, são os que contém as regras de negócio, é onde a lógica do aplicativo está. Essa foi a parte teórica sobre controllers. Agora vamos à parte prática, onde será mostrada a estrutura, função e funcionamento de um controller.

Controllers no CodeIgniter

Controllers no CodeIgniter são simplesmente arquivos com uma classe que é nomeada de forma ser associada a uma URL. Complicado? Lendo o artigo sobre URLs no CodeIgniter você vai ver que não!

Se temos, por exemplo, uma URI como http://www.site.com.br/noticias/, isso significa que a clase Noticias, contida no arquivo noticias.php, entrará em ação. Quando o nome de um controller bate com o primeiro segmento de uma URL, então esse controller é carregado.

Lembrando da estrutura de diretórios do CodeIgniter, veremos que os arquivos dos controllers devem ser colocados em application/controllers a fim de garantir uma boa organização das pastas do projeto. Há pessoas que optam por armazenar seus controllers em outros locais e há, também, a possibilidade de modularização no CodeIgniter através do uso de algumas bilbiotecas – mas esses são assuntos para artigos futuros.

Reapitulando o que consta no artigo sobre MVC, temos as seguintes características básicas de um controller:

• Define o comportamento da aplicação;
• Mapeia ações para atualizar models;
• Seleciona views para exibição;
• Deve haver um controller para cada “funcionalidade”.

Estrutura de um Controller no CodeIgniter

Assim como todo framework, o CodeIgniter possui suas regras de sintaxe, ou seja, a maneira pela qual os códigos devem ser escritos. A estrutura básica de um controller no CodeIgniter (para fins didáticos, “Noticias”) é a seguinte:

1
2
3
4
5
6
7
8
9
10
11
12
13
14

class Noticias extends Controller
{
    function Noticias()
    {
        parent::Controller();
    }
 
    function index()
    {
        echo 'Olá, mundo!';
    }
 
    // demais funções
}

O nome da classe deve iniciar com letra maiúscula

Perceba como está a estrutura-base do exemplo. Isso é certo:

class Noticias extends Controller
{
}

Isso é errado:

class noticias extends Controller
{
}

Deve haver um construtor

Basta criar uma função com o mesmo nome da classe e estender a classe Controller, como mostrado no exemplo. Se tivéssemos uma classe Matematica, ficaria:

1
2
3
4
5
6
7

class Matematica extends Controller
{
    function Matematica()
    {
        parent::Controller();
    }
}

Sempre “parent::Controller();” deve estar presente, mas não necessariamente deve ser a única instrução. Se quiser executar algum código no construtor da classe, isso também é permitido.

O arquivo deve ter o mesmo nome da classe

Cada classe (controller) deve contar um e somente um arquivo para si. Não coloque mais de uma classe em um arquivo de controller, porque isso não vai funcionar. Em nosso controller de exemplo “Noticias”, o arquivo que o conteria seria o noticipas.php. O caminho para o arquivo seria application/controllers/noticias.php.

É possível, também, ter subpastas dentro da pasta “controllers”, a fim de melhor organizar um projeto. Nesse caso, o primeiro segmento da URL será a pasta e o segundo segmento será o controller. Então, se tivéssemos o arquivo application/controllers/produtos/eletronicos.php, o acesso a uma de suas funções – por exemplo, listar() – se daria através do endereço “http://www.site.com.br/produtos/eletronicos/listar/”.

A função index() é a primeira a ser executada

Em nosso exemplo do controller Noticias, vejam que existe uma função index(). Essa é a função que será executada quando http://www.site.com.br/noticias/ for acessado. Todas as intruções que estiverem na função index() serão executados.

Funções em um Controller no CodeIgniter

Recapitulando o que já foi visto no post sobre URLs no CodeIgniter, os parâmetros das funções em um controller também podem ser passadas via URL. Por padrão, o controller, em si, é  o primeiro segmento da URL; o próximo é um função do controller; e os subsequentes, parâmetros dessa função.

Repetindo o exemplo do artigo sobre URLs, vejamos o seguinte controller:

1
2
3
4
5
6
7

class Matematica extends Controller
{
    function soma($x, $y)
    {
        echo $x + $y;
    }
}

Um belo “10″ será mostrado na tela para quem acessar http://www.site.com.br/matematica/soma/5/5.

Funções privadas em controllers

Em determinadas situações, você pode querer criar funções que não são acessíveis via URL – o método “tradicional” de acesso a funções no CI. Para fazer isso, você deve criar funções privadas (cujo nome é precedido por underscore) da seguinte forma:

function _funcaoqualquer()
{
  // códigos
}

Tentando acessar http://www.site.com.br/noticias/_funcaoqualquer/, não vai funcionar (afinal, trata-se de uma função privada).

Definindo um Controller padrão

É possível definir um controller padrão para seu software, quer dizer, um que será executado quando, na URL, nenhum outro for indicado, ou seja, quando a aplicação for acessada, através de seu endereço principal. É como definir a “página inicial” de um software ou site.

Para especificar qual será esse controller default, acesse o arquivo application/config/routes.php e altere a diretiva $route['default_controller'] com o nome do controller desejado. Por exemplo:

$route['default_controller'] = 'Noticias';

Ao acessar o fictício http://www.site.com.br/, as instruções da função index() do controller Noticias serão executadas automaticamente.

E isso é tudo sobre controllers no CodeIgniter?

Não, ainda há mais coisas a respeito dos controllers no CodeIgniter. Por exemplo, já que você estende a classe nativa Controller em seus controllers, você não pode nomear suas funções com algum dos nomes reservados das funções nativas de controller do CodeIgniter.

E ainda há mais sobre controllers, recursos e técnicas que podem ser feitos para ampliar ainda mais seu poder. Mas, pode ter certeza, essa já é uma boa fonte de informação sobre controllers no CodeIgniter. Não é?  ;-)

URLs no CodeIgniter

No artigo sobre MVC foi visto que, no CodeIgniter, os controllers são responsáveis por controlar todo o fluxo do software; a lógica da coisa; as regras de negócio do sistema. Por padrão, as URLs no CodeIgniter são feitas para serem URLs amigáveis (Friendly URLs),quer dizer, são apresentadas em uma estrutura propícia para as páginas do site/sistema serem melhor indexadas por mecanismos de busca, tais como o Google. Em outras palavras, as URLs no CodeIgniter são baseadas em segmentos.

Estrutura de URL no CodeIgniter

Vamos tomar por exemplo o seguinte endereço, gerado a partir de um sistema fictício, feito em CodeIgniter:

http://www.site.com.br/noticias/artigos/meu_artigo

Como podemos ver, trata-se de um URI normal, que pode ser encontrado em milhares de sites por aí. Então, dentro do CodeIgniter, isso é interpretado da seguinte maneira:

http://www.site.com.br/classe/funcao/id

E, dentro dessa estrutura de URL, o significado de cada segmento:

1. classe. O primeiro segmento, “noticias”, representa o controller (classe) “noticias”.
2. funcao. O segundo segmento, “artigos”, é uma função (funcao) que existe no controller “noticias”.
3. id. O terceiro, “meu_artigo”, é o parâmetro (id) da função “artigos” do controller “noticias”.

Quer dizer, existe um controller “noticias” que possui uma função “artigos” (função esta que recebe um parâmetro, “id”, para funcionar):

class Noticias extends Controller
{
    function artigos($id)
    {
        // código da função
    }
}

Não se preocupe com essa estrutura, ela será melhor detalhada no artigo sobre Controllers.

Vamos supor que precisássemos de uma função com 2 parâmetros. O CodeIgniter entende, também:

class Matematica extends Controller
{
    function soma($x, $y)
    {
        echo $x + $y;
    }
}

Um belo “10″ será mostrado na tela para quem acessar o URI:

http://www.site.com.br/matematica/soma/5/5

Removendo o segmento “index.php”

Em uma instalação do CodeIgniter padrão, o segmento “index.php” será sempre mostrado (isso devido a “questões internas”, digamos assim). Mas, caso se queira, é possível retirar do URL. Para tal, temos que nos valer de algumas poucas instruções em um arquivo .htaccess:

RewriteEngine on
RewriteCond $1 !^(index\.php|images|robots\.txt)
RewriteRule ^(.*)$ /index.php/$1 [L]

O código mostrado faz com que qualquer solicitação HTTP que não sejam para “index.php”, imagens e “robots.txt” é tratada como uma solicitação para o arquivo index.php (mesmo “index.php” não aparecendo na URI).

Em função de configurações de servidor, algumas vezes o .htaccess mostrado pode não funcionar. Caso isso aconteça com você, dê uma olhada nesse artigo sobre problemas de htaccess no CodeIgniter.

Adicionando sufixo ao URL

É possível brincar um pouco mais com as URIs no CodeIgniter. Um dos recursos interessantes é acrescentar um sufixo no URI, “dando a impressão” de que se está acessando um arquivo.

Veja no arquivo de configuração do CodeIgniter (/system/application/config/config.php) a seção “URL suffix”. É lá que você vai alterar a variável $config['url_suffix'] e inserir o que você quer que seja seu sufixo. Por exemplo, você pode ter URIs como:

http://www.site.com.br/noticias/artigos/meu_artigo.html

Trabalhando com Query Strings

Como foi visto, por padrão, o CodeIgniter apresenta uma estrutura de URLs amigáveis. Mas o framework possui tanta flexibilidade e opções de configuração e uso que é possível trabalhar com query strings. Isso, mesmo! Se você quer reviver a “tradição” na internet e fazer com que seu sistema pareça ter sido feito há 10 anos atrás, é possível apresentar query strings!

Para isso, você deve ir ao arquivo de configuração citado (config.php) e, na seção “Enable Query Strings”, alterar a diretiva $config['enable_query_strings'] para “TRUE”, ficando dessa maneira:

$config['enable_query_strings'] = TRUE;
$config['controller_trigger'] = 'c';
$config['function_trigger'] = 'm';

Percebam as 2 outras diretivas. É possível configurar os “triggers” que representam, respectivamente, o controller e a função que se deseja usar. Dando um exemplo de como ficaria um URI usando as query strings (e os triggers default do CodeIgniter), teríamos algo como:

index.php?c=estatisticas&m=mostrar

Quer dizer, será executado o código da função “mostrar” do controller “estatisticas”. Nostálgico…

Conclusão sobre URLs no CodeIgniter

É gritante a facilidade com a qual se trabalha com URLs no CodeIgniter! Através de uma estrutura baseada em segmentos, os endereços gerados são fáceis para uma melhor indexação do site/sistema por mecanismos de busca, ao mesmo tempo em que oferece uma capacidade incrível para se trabalhar com as funções (nativas e criadas) do framework.

A flexibilidade é tamanha que é até possível mexer com query strings – mesmo que, para isso, tenhamos que abrir mão de alguns recursos nativos muito úteis.

Com certeza o CodeIgniter, provando mais uma vez que é o melhor framework PHP, mostrou que um dos pilares de seu poder de funcionamento é sua estrutura de URLs!

Estrutura de diretórios: organização de pastas do CodeIgniter

Estrutura de diretórios do CodeIgniter

Não dá pra trabalhar com o CodeIgniter sem conhecer sua estrutura de diretórios. É conhecendo como é a organização das pastas no CodeIgniter e sabendo sua função dentro do “todo” do framework que é possível mexer no CI com eficiência e consciência – também é importantíssimo conhecer o Fluxograma de Dados do CodeIgniter (se ainda não leu o artigo, leia antes de continuar).

Com um pouco mais de experiência é possível alterar a estrutura de diretórios do CodeIgniter, mas, para fins didáticos, será mostrada no tutorial a estrutura padrão de pastas do CI – dentro do momento histórico da atual versão do framework, CodeIgniter 1.7.2.

Não serão detalhadas as funções/possibilidades completas de cada pasta e seus respectivos arquivos; isso será feito, com o tempo, na medida em que novos artigos são publicados no blog. Portanto, não é preciso ficar frustrado caso encontre termos que ainda desconhece; assine o feed do CodeIgniter Brasil para não perder as atualizações.  ;-)

Visão geral da estrutura de pastas do CodeIgniter

Como pode ser visto na imagem da estrutura de pastas acima, na raiz da estrutura do CodeIgniter existem 2 diretórios e 2 arquivos.

Diretórios

Os 2 diretórios existentes na raiz da estrutura do CodeIgniter são:

• system. Local onde os códigos das aplicações/softwares desenvolvidos ficam.
• user_guide. Contém o Guia do Usuário (User Guide) do CodeIgniter (cópia da documentação online).

Arquivos

Juntamente com os diretórios supracitados, na raiz do esquema de diretórios do CodeIgniter existem 2 arquivos:

• index.php. Primordial para o funcionamento do CI, contém informações para se alterar o nível de error reporting que se vai trabalhar; opcionalmente, também é possível alterar os nomes padrão da pasta “system” e “application” (mais a respeito: Instalação e configuração inicial do CodeIgniter).
• licente.txt. É o arquivo com a licença do CI que, como já foi tratado no artigo sobre requisitos de servidor e licença de uso, deve constar em todo software/aplicativo feito em CodeIgniter.

system

Na pasta system toda a “ação” do CI acontece. Para organizar a estrutura presente, há subpastas para segmentar e organizar os arquivos e fluxo de trabalho.

• application. Pasta onde os arquivos do aplicativo desenvolvido ficam. Praticamente toda a codificação em CI fica nesta pasta, que abriga seus models, views, controllers e outros que ainda serão tratados no blog.
• cache. No CodeIgniter existem maneiras de trabalhar com cache para servir aplicativos mais rápidos e robustos para quem os utilizam. É nesta pasta que arquivos condizentes ao cache feito são armazenados.
• codeigniter. Os arquivos de core ficam aqui. É nesta pasta que está o “coração” do CodeIgniter. Raramente é preciso mexer em algo nesta pasta, já que todo o desenvolvimento do software se dá na pasta “application”.
• database. Contém os core files (drivers e outras coisas) para trabalhar com bancos de dados. Assim como a pasta “codeigniter”, raramente será preciso mexer nela.
• fonts. Basicamente, esta pasta é para armazenar as fontes que podem ser usadas pela biblioteca de manipulação de imagens (que também será vista em outro momento aqui no CodeIgniter Brasil).
• helpers. Pasta que contém os helpers nativos do Code Igniter (para mexer com arrays, cookies, diretórios, e-mails, formulários e muitos outros).
• language. Contém arquivos de idioma (que são usados principalmente para mensagens das libraries e helpers).
• libraries. Pasta de armazenagem das libraries (bibliotecas) padrão do CI para códigos envolvendo e-mails, calendários, upload de arquivos e mais.
• logs. Como sugere o nome, esta pasta armazena todos os logs gerados pelo CodeIgniter.
• plugins. Contém os plugins default do CodeIgniter. Veremos com mais detalhes futuramente, mas a diferença básica entre helpers e plugins é que os plugins possuem somente 1 função (e geralmente são feitos com intenção de serem compartilhados com a comunidade CI).
• scaffolding. Contém os arquivos necessários para se trabalhar com scaffolding no CodeIgniter. Se ainda não sabe o que é isso, não se preocupe, ainda vamos abordar o scaffolding (e, temos certeza, você vai se surpreender).

system/application

Sem dúvidas, a pasta system/application é a mais importante para o desenvolvimento dos aplicativos e é a que mais vai exigir sua atenção/codificação. Já que a maior parte do seu trabalho vai ser aqui, é importante conhecer bem a estrutura de subdiretórios da pasta “application”:

• config. Contém diversos (e importantes) arquivos relacionados a configurações de seu CI. São arquivos de configuração de database, variáveis sobre URL, quais libraries e helpers serão carregados automaticamente e muitas outras coisas.
• controllers. Armazena os controllers que você cria para o seu software.
• errors. Vem com os templates de páginas de erros do CodeIgniter (erros genéricos, 404, conexão ao banco de dados, etc). É conveniente que tudo isso seja alterado para que os erros do aplicativo fiquem personalizados e consonantes com a finalidade deste.
• helpers. Para armazenar todos os helpers que você venha a criar/aprimorar.
• hooks. Para colocar os hooks que você cria. Em artigos futuros será mostrado que hooks são a maneira mais rápida e segura de você extender o core do CodeIgniter (geralmente feito por usuários avançados).
• language. Para aplicativos multi-idioma, esta pasta é bem usada por armazenar as mensagens nas diferentes escritas.
• libraries. Aqui ficam as libraries personalizadas, com funcionalidades para o programa a ser criado. Perceba que há diferença entre as pastas system/libraries e system/application/libraries.
• models. Armazena os models que você cria para seu aplicativo.
• views. Armazena os views que você cria para seu programa.

1
2
3

RewriteEngine on
RewriteCond $1 !^(index\.php|img|css|js)
RewriteRule ^(.*)$ index.php/$1 [L]

O importante é a função de cada pasta

Principalmente quando se está começando, é bastante comum ficar em dúvida sobre a função de cada diretório e ter receio de criar arquivos no lugar errado. Estudando a estrutura de pastas do CodeIgniter, certamente esse não será um problema que irá travar seu processo de desenvolvimento.

O CodeIgniter foi projetado para manter seguros seus arquivos de core e é por uma razão que existe uma pasta específica para você criar os arquivos de seu software. Você deve concentrar seus arquivos em system/application, criando arquivos nos diretórios adequados – conforme foi abordado neste artigo – e somente criar/alterar arquivos de outras pastas caso você saiba exatamente o que está fazendo (e tenha um bom motivo pra isso).

Categorias

• Configurações (1)
• Diversos (3)
• Passos Iniciais (16)