Drivers no CodeIgniter, apesar de ser algo relativamente novo no framework, não tem nada de complicado. Na verdade, drivers não passam de bibliotecas, mas com característica e modo de usar ligeiramente diferentes. Como já foi abordado aqui, no CodeIgniter Brasil, como carregar bibliotecas e como criar bibliotecas no CodeIgniter, chegou a hora de abordar os Drivers do CodeIgniter.

Drivers no CodeIgniter

Como foi dito, drivers são, somente, um tipo diferente de library que trabalha mais com o conceito de herança do PHP, quer dizer, existe uma classe mãe e outras classes filhas quaisquer. Classes filhas têm acesso à classe mãe, mas não a suas “classes irmãs”.

Então, drivers podem ser usados em situações em que a programação e organização de uma ou mais bibliotecas de um projeto sejam beneficiados ao serem esta(s) classe(s) dividida(s) em diversas outras classes.

Criando drivers no CodeIgniter

Drivers devem ser criados no diretório system/libraries, em sua própria pasta, que deve ter o mesmo nome da classe mãe. Dentro deste diretório deve existir outra pasta chamada drivers, que conterá todas as possíveis classes filhas.

Para que fique mais claro, veja o seguinte modelo de estrutura de drivers no CodeIgniter:

• /application/libraries/Driver_name
• Driver_name.php
• drivers
• Driver_name_subclass_1.php
• Driver_name_subclass_2.php
• Driver_name_subclass_3.php

Usando drivers no CodeIgniter

Para usar um driver, primeira é preciso inicializá-lo (tal como fazemos com libraries) da seguinte maneira:

$this->load->driver('driver_name');

Métodos dessa classe são invocados usando:

$this->driver_name->method();

As classes filhas – os drivers, propriamente ditos – podem ser chamados diretamente por sua classe mãe, sem a necessidade de iniciar cada uma delas:

$this->driver_name->child_one->some_method();
$this->driver_name->child_two->another_method();

Bem tranquilo, certo? Como dissemos, não passam de bibliotecas do CI.

Exemplo de driver no CodeIgniter

Pelo fato de já termos passado sobre alguns artigos sobre libraries e pelo conceito e conteúdo deste artigo, já é possível entender o funcionamento e dinâmica dos drivers no CodeIgniter. Mas, para fixar um conceito, é sempre interessante a visualização e análise de algum exemplo concreto.

E, para o caso, indico o projeto no GitHub que foi criado, justamente, para servir de exemplo: CI2_Drivers_example.

Ao baixar e analisar os arquivos, certamente você entenderá melhor como é funcionamento deste recursos interessantíssimo do framework e poderá, a partir de agora, julgar corretamente ao escolher quando usar drivers no CodeIgniter.

Bibliotecas (ou libraries) no CodeIgniter são importantíssimas, pois, através delas, podemos estender recursos do framework, seja criando nossas próprias bibliotecas ou pegando recursos já prontos disponibilizados pela comunidade. Para o primeiro caso, aprenda como criar bibliotecas no CodeIgniter e veja como essa criação é simples e fácil de ser feita.

O que são as bibliotecas no CodeIgniter

Bibliotecas no CodeIgniter nada mais são do que classes PHP localizadas em /application/libraries. Perceba que existe, também, a pasta /system/libraries/, mas como foi visto no artigo sobre a estrutura de diretórios do CodeIgniter, dentro de /system ficam os arquivos de core do CI, portanto, é prudente mexer ali somente quando realmente souber o que está fazendo.

Fique sabendo, também, que, caso crie uma biblioteca com o mesmo nome de alguma biblioteca nativa do CodeIgniter, esta será sobreescrita pelo seu código! Tenha muita atenção!

Convenções sobre libraries no CodeIgniter

Em relação a bibliotecas no CI, com exceção das que são para mexer com bancos de dados, é possível:

• Criar novas bibliotecas
• Estender bibliotecas nativas
• Sobreescrever bibliotecas nativas (!)

Como vimos, os arquivos devem ser criados em /application/libraries e seguir as seguintes convenções:

• O nome deve capitalizado. Por exemplo: Minhalib.php
• A declaração da classe também: class Minhalib
• O nome do arquivo e da classe devem ser o mesmo (vide exemplos acima)

Veja este protótipo de como deve ser uma library no CodeIgniter:

1
2
3
4
5
6
7
8
9
10
11

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed'); 
 
class Minhalib {
    public function __construct()
    {
    }
 
    [...]
}
 
/* End of file Minhalib.php */

E pronto! Já temos uma biblioteca pronta e já podemos usá-la em nossa aplicação! Para usar, você já sabe, basta seguir o que foi explicado no artigo “Carregando bibliotecas (libraries) no CodeIgniter“. Em um controller, basta usar:

1

$this->load->library('minhalib'); // Em minúsculo, mesmo

E, depois, usar quaisquer funções que sua library contenha. Vamos passar nosso modelo para o seguinte:

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

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed'); 
 
class Minhalib {
    public function __construct()
    {
    }
 
    public function ola_mundo()
    {
        return 'Ol&aacute; mundo!';
    }
}
 
/* End of file Minhalib.php */

Então, depois de carregar a biblioteca, para se usar a função ola_mundo(), basta codificar:

1

$this->minhalib->ola_mundo(); // Sempre em minúsculo

No caso, como temos um retorno em texto, caso fosse preciso escrever esse retorno:

1

echo $this->minhalib->ola_mundo();

Passando parâmetros no carregamento da biblioteca

É bastante comum ser preciso passar alguns parâmetros na invocação de uma biblioteca. Evidentemente o CI permite fazer isso de uma maneira bastante simples. Primeiramente, vamos preparar nossa classe para receber parâmetros:

1
2
3
4
5
6
7
8
9
10
11

<?php if ( ! defined('BASEPATH')) exit('No direct script access allowed'); 
 
class Minhalib {
    public function __construct($parametros)
    {
    }
 
    [...]
}
 
/* End of file Minhalib.php */

Com isso feito, os $parametros passados o devem ser através de um array (chave/valor). Dessa maneira, na inicialização da classe teríamos algo como:

1

$this->load->library('minhalib', array('chave1' => 'valor1', 'chave2' => 'valor2'));

Ou, para facilitar a leitura e entendimento posteriores:

1
2

$parametros = array('chave1' => 'valor1', 'chave2' => 'valor2');
$this->load->library('minhalib', $parametros);

Então, você pode fazer o que quiser com esses parâmetros. Só por curiosidade, execute o código acima depois de mudar a biblioteca para:

1
2
3
4
5
6

class Minhalib {
    public function __construct($parametros)
    {
        print_r($parametros);
    }
}

Usando recursos do CodeIgniter em bibliotecas

É perfeitamente possível (e frequentemente necessário) utilizar recursos nativos do CodeIgniter em bibliotecas que criamos. Mas, para isso, é preciso fazer uma coisinha antes. Como foi visto anteriormente, para chamarmos algum recurso do CI devemos nos valer de funções usando o $this, mas, no contexto de criação/edição de bibliotecas, isso não funciona; o $this só funciona, por padrão, para models, views e controllers.

Então, para se usar recursos nativos do CodeIgniter em bibliotecas próprias, é preciso atribuir por referência o super objeto do CodeIgniter a uma variável:

1

$CI =& get_instance();

A partir de então, temos acesso a todos os recursos nativos usando a variável $CI (ou qualquer outro nome que você queira):

1
2
3

$CI->load->helper('url');
$CI->load->library('session');
[...]

Estendendo bibliotecas nativas do CodeIgniter

Foi explicado no artigo sobre MY_Controller que é possível estender o “controller base” CI_Controller. O mesmo raciocínio se aplica para o caso de ser preciso estender libraries nativas do CI e, para se fazer isso, é um processo tão simples quanto.

Por exemplo, caso queiramos estender as funcionalidades da library nativa de e-mails, nos valemos do já conhecido prefixo de subclasse “MY_” (ou o que você tenha definido em /application/config/config.php):

1
2
3
4
5
6

class MY_Email extends CI_Email {
    public function minha_funcao()
    {
        [...]
    }
}

E, para os (não raros) casos em que é preciso chamar o construtor da superclasse na inicialização da biblioteca:

1
2
3
4
5
6
7
8
9
10
11

class MY_Email extends CI_Email {
    public function __construct()
    {
        parent::__construct();
    }
 
    public function minha_funcao()
    {
        [...]
    }
}

Feitos os devidos acréscimos de funcionalidades, a chamada para a biblioteca e o uso das funções não se altera em nada:

1
2

$this->load->library('email'); // SEM o prefixo "MY_"
$this->email->minha_funcao();

Simples, rápido, objetivo, enfim, nenhum mistério no mundo PHP OO!

Conclusão

Como vimos, criar bibliotecas no CodeIgniter é bastante simples. Seguindo algumas pequenas convenções de localização e nomenclatura, é possível criar funcionalidades espetaculares e/ou estender as (também espetaculares) funcionalidades do CI. Afinal, é para isso que serve um framework! Sua produtividade agradece!

Ah, e espero que você tenha notado o quão fácil é integrar classes feitas em PHP puro ao CodeIgniter, simplesmente as “transformando” em bibliotecas do framework! ;-)

Lembrando das lições básicas sobre controllers no CodeIgniter, vimos que, quando criamos um novo controller para um projeto, devemos estender o “CI_Controller”. Isso nada mais é do que PHP OO básico: uma classe estendendo outra para adquirir as propriedades e métodos permitidos.

Seguindo a OO, o CodeIgniter permite, de forma bastante simples, estender suas principais classes, adicionando ou substituindo funcionalidades a suas classes de sistema ou, como mais comumente conhecidas, core classes.

Toda vez que o CodeIgniter roda, essas core classes são iniciadas automaticamente (por serem essenciais ao funcionamento do framework) e, ao estender ou modificar alguma funcionalidade delas, a modificação é iniciada também automaticamente, conferindo um nível de adaptação e flexibilidades incríveis a qualquer projeto! Estas são as core classes que são chamadas toda vez que o CI roda (localizadas em /system/core):

O “segredo” para estender/modificar estas classes está no diretório /application/core (veja o artigo sobre a estrutura de diretórios no CodeIgniter).

Estender as core classes do CodeIgniter

Em tempo oportuno serão mostradas, aqui no CodeIgniter Brasil, as funcionalidades de todas as classes do CodeIgniter. Por enquanto, basta saber que, mesmo suas funcionalidades padrão já serem poderosíssimas, é possível estendê-las, conferindo mais poder e flexibilidade no momento de desenvolver projetos.

Então, por exemplo, caso queira estender a classe de Input do CI (/system/core/Input.php), basta criar o arquivo /application/core/MY_Input.php e partir do seguinte ponto:

1
2
3
4
5
6
7
8
9

class MY_Input extends CI_Input {
 
    function __construct()
    {
        parent::__construct();
    }
 
    // Seu código aqui
}

A partir deste trecho de código, podemos deduzir 2 importantes informações:

• Prefixo para o nome da classe. Ao estender uma core classe do CodeIgniter, é preciso que o nome da classe seja “prefixo” + “nome”, como no exemplo “MY_Input”.
• Declaração “extends”. Sua classe deve, necessariamente, estender a classe-pai que se deseja manipular propriedades/métodos. No exemplo, a classe MY_Input estendeu a classe CI_Input (localizada em /system/core/Input.php).

Para quem já está familiarizado com PHP OO (o que, aliás, é um pré-requisito para se trabalhar com CI), a única novidade ficou por conta do prefixo necessário ao nome da classe. Como é de se esperar, caso você use um nome de método igual a algum já existem na core classe, toda a classe será substituída por suas novas instruções, portanto, atenção a isso!

Aliás, este prefixo pode ser outro, conforme sua vontade. Basta abrir o arquivo /application/config/config.php e alterar a diretiva “subclass_prefix” – por razões óbvias, não é possível alterar para “CI_”…

Substituir as core classes do CodeIgniter

Para substituir as core classes do CodeIgniter, basta criar um arquivo com o mesmo nome da “classe alvo”. Por exemplo, para substituir a classe de Input, basta criar o arquivo /application/core/Input.php com o seguinte código-base:

1
2
3

class CI_Input {
    // seu código aqui
}

O prefixo “CI_” é necessário para que o framework entenda do que se trata. Então, para substituir as core classes, basta seguir este modelo acima, sempre lembrando de usar o prefixo indicado.

Como já vimos no artigo sobre Controllers no CodeIgniter, todo controller que criamos deve estender o controller “original” CI_Controller:

class Usuario extends CI_Controller {
     // código
}

Isso é simplesmente PHP Orientado a Objetos no qual, no exemplo, a classe “Usuario” estende a classe “CI_Controller” para herdar os métodos e propriedades herdáveis (públicos e protegidos).

Como estamos falando do bom e “velho” PHP OO, pensem comigo: seria possível, também, estender o próprio CI_Controller, já que se trata, tão somente, de uma classe em PHP? A boa notícia é que, sim, é possível estender o CI_Controller e adicionar novas funcionalidades ao “controller-mor” do CodeIgniter!

MY_Controller

Podemos encontrar no arquivo principal de configuração do CodeIgniter, em /application/config/config.php a diretiva de qual é o prefixo a ser usado para estender classes nativas. Por padrão, é “MY_” (mas pode ser alterado):

$config['subclass_prefix'] = 'MY_';

Ou seja, quando queremos estender libraries nativas (e alguns outros recursos, também), usamos o prefixo especificado nesta diretiva.

Então para estender o CI_Controller, é preciso criar o arquivo /application/core/MY_Controller.php e usar o modelo:

class MY_Controller extends CI_Controller {
     // código
}

Se não, vejamos: já que estendemos o CI_Controller para usar métodos e propriedades gerais, não faz mais sentido os controllers “comuns” estenderem o CI_Controller, já que ele continua o mesmo da instalação original. Portanto, a partir do momento em que se quer estender as funcionalidades do CI usando esta técnica, todos os controller devem, a partir de agora, estender o MY_Controller!

Nosso exemplo mudaria para:

class Usuario extends MY_Controller {
     // código
}

Ficando com a seguinte hierarquia:

CI_Controller > MY_Controller > Usuario (e demais controllers)

Benefícios de uso do MY_Controller

Ao usar o MY_Controller temos tantos benefícios quantos podem ser necessários/requeridos em um projeto. Obviamente esta técnica não é para ser usada sem critérios, mas alguns pontos são indicativos de quando devemos nos valer do MY_Controller:

• Se determinados métodos e/ou propriedades devem (ou tem a chance de ser) usados em muitos controllers
• Criação de métodos específicos que ajudarão e poderão ser usados em muitos controllers
• Variáveis (propriedades) usadas em todos ou muitos controllers

Porque, agora, os controllers do projeto que estendem o MY_Controller tem acesso a todas as funções e variáveis de CI_Controller e MY_Controller (conforme pode ser visto na representação da hierarquia acima). Vamos a um exemplo de uma função útil que pode constar no MY_Controller:

class MY_Controller extends CI_Controller {
 
    public function is_ajax()
    {
        return (isset($_SERVER['HTTP_X_REQUESTED_WITH']) && $_SERVER['HTTP_X_REQUESTED_WITH'] == 'XMLHttpRequest');
    }
 
}

Nisso, todos os controllers que estenderem o MY_Controller contarão com o método is_ajax(), que testa se a requisição à classe está sendo feita via AJAX ou não. Poderíamos ter, por exemplo, algo assim:

class Usuario extends MY_Controller {
 
    public function get_by_name()
    {
        if ($this->is_ajax())
        {
            // Se for AJAX...
        }
        else
        {
            // Se não for AJAX...
        }
    }
 
}

Conclusão

Como pudemos ver, há casos em que todos ou a maioria dos controllers precisam acessar ou serem capazes de realizar determinados métodos e/ou ter determinadas propriedades em comum.

Caso seja esse seu caso, é possível facilitar a produção e a manutenção de códigos usando o MY_Controller!

Vimos no artigo “Models, Views e Controllers trabalhando juntos no CodeIgniter” como é feita a “passagem” de dados numa aplicação em CodeIgniter e como se faz para exibir informações nas views.

Bem, esse é o método “tradicional” de se trabalhar nas views, mas não o único! Já existe no CodeIgniter, nativamente, uma maneira de deixar os views mais enxutos e facilmente inteligíveis; uma maneira de exibir dados mais fácil e rapidamente; e essa maneira é usar a Template Parser Class do CodeIgniter!

O que é a Template Parser Class

A Template Parser Class é uma classe nativa do CodeIgniter que permite usar o sistema de “parser” em pseudo-variáveis nas views. Se você ainda não trabalhou com template engines, então veja a nítida diferença entre exibir dados assim:

1
2
3
4
5
6

<h1><?php echo $title ?></h1>
 
<?php foreach($posts as $p): ?>
    <h1><a href="/blog/<?php echo $p->slug ?>"><?php echo $p->title ?></a></h1>
    <?php echo $p->content ?>
<?php endforeach ?>

E assim:

1
2
3
4
5
6

<h1>{$title}</h1>
 
{posts}
    <h1><a href="/blog/{slug}">{title}</a></h1>
    {content}
{/posts}

E aí, qual você prefere? ;-)

Como usar a Template Parser Class do CodeIgniter

Se você gostou dessa maneira “diferente” de apresentar seus dados nas views, saiba que é muito simples começar a usar a Template Parser Class!

Primeira, você deve carregar a biblioteca (ou configurar para auto carregar, como conta no artigo) de parser:

$this->load->library('parser');

No controller

Tomemos um controller fictício para exemplificar o uso do parser. Primeiro carregamos a library (caso não esteja auto carregada), pegar os dados do model, normalmente, mas, ao invés de darmos um load em alguma view usando $this->load->view(), chamamos o “método-base” da Template Parser Class:

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

// Carrega Template Parser Class
$this->load->library('parser');
 
// Carrega um model de Blog qualquer
$this->load->model('Blog_model');
 
// Pega algumas informações do BD	
$data['title'] = 'Blog de Testes do CodeIgniter';
$data['posts'] = $this->Blog_model->get_posts(5);
 
// Chama a view "parseada"
$this->parser->parse('blog_index', $data);

Perceba o seguinte neste método:

• Primeiro parâmetro. É o nome da view que se deseja “parsear” (“blog_index”).
• Segundo parâmetro. Dados enviados para o “parseamento” ($data).

Dessa maneira, como foi visto no início do artigo, é possível usar a seguinte sintaxe para exibição de dados nas views:

1
2
3
4
5
6

<h1>{$title}</h1>
 
{posts}
    <h1><a href="/blog/{slug}">{title}</a></h1>
    {content}
{/posts}

Veja que, para as variáveis simples, não é preciso echo(), print() ou qualquer função de exibição que seja. Basta envolver o nome da pseudo-variável entre colchetes que funciona! Para sets de resultados vindos do BD ou algum array multidimensional de dados, nos quais, para cada iterador, há valores diferentes a serem exibidos, basta “abrir” e “fechar” o par de pseudo-variáveis, tal como consta no exemplo.

Há um terceiro parâmetro, booleano, opcional, que pode ser usado para, ao invés de já enviar as pseudo-variáveis para serem exibidas, retorna o valor do “parseamento” para ser usado de alguma outra forma na view:

1

$this->parser->parse('blog_index', $data, TRUE);

E existe, também, um método para parsear strings ao invés de views. Caso queira saber mais a respeito, veja o método $this->parser->parse_string() na documentação oficial.

Conclusão sobre o template engine do CodeIgniter

Como foi visto, usar o template engine do CodeIgniter para fazer o parser de pseudo-variáveis nas views é bastante simples e intuitivo. Além de reduzir o tamanho do código e poupar tempo de escrita, o código fica tão fácil de entender que até os designers conseguirão realizar pequenas manutenções em views! ;-)

É uma template engine básica, sem maiores recursos de outras mais poderosas que podemos encontrar por aí, mas, até para CI existem recursos de terceiros que aprimoram isso. Provavelmente estes serão mostrados em artigos futuros, não percam!

É verdade que há um consumo de recursos ligeiramente mais elevado do que se não estivéssemos usando um echo(), mas isso não é considerável para projetos pequenos e médios, então a Template Parser Class pode ser usada sem preocupações!

No artigo apresentando as classes do CodeIgniter demos uma passada geral em algumas das funcionalidades do framework. Como pôde ser visto, o CodeIgniter já vem com uma série de classes, funcões e funcionalidades para facilitar, e muito, a vida do programador!

Mas, para usarmos e nos valermos deste poder, é preciso, antes, que saibamos como “chamar” este poder. E este artigo mostrará justamente isso: como carregar e usar bibliotecas do CodeIgniter!

Loader

Existe, no core do CodeIgniter, uma classe que é iniciada sempre e automaticamente, responsável por prover o loader dos recursos do CI: é a Loader (“carregador”). Através desta classe é possível carregar recursos do CI, tais como views, helpers e libraries, models e outros.

Basicamente, a loader possui uma sintaxe bastante comum entre os diferentes recursos que podem ser chamadas, diferindo, somente, em algum parâmetros. Veremos, a seguir, como carregar um dos recursos mais comuns do CodeIgniter> libraries.

Como carregar uma library no CodeIgniter

Para se carregar uma library (ou, se preferir, “biblioteca”) no CodeIgniter, use o seguinte:

$this->load->library('classe', $config, 'alias')

Ou seja: o primeiro parâmetro é o nome do recurso que se deseja carregar; o segundo, as configurações desta classe e; o terceiro, seu alias (apelido).

Nome da library

Por exemplo, para carregar as funcionalidades de e-mail do CodeIgniter, usa-se o seguinte (em qualquer controller):

$this->load->library('email');

Pronto, as funcionalidades de e-mail já estão prontas para serem usadas! Uma vez carregada a classe, você precisará acessar os métodos desta e, para isso, usa-se o modelo:

$this->email->funcao()

Por exemplo, a classe library possui a função to() que serve para especificar para quem o e-mail será enviado. Depois de carregada a classe, usa-se

$this->email->to('fulano.de.tal@exemplo.com.br');

Não se preocupe com funções específicas no momento. Futuramente, explicaremos o uso de todas as funcionalidades do CI aqui no CodeIgniter Brasil. ;-)

Configurações

O segundo parâmetro (opcional), como vimos, é a configuração que se quer quando o recurso for inicializado. Por exemplo:

$config = array (
    'mailtype' => 'html',
    'charset'  => 'utf-8,
    'priority' => '1'
);
 
$this->load->library('email', $config);

Ou seja, através de um array de configurações, passamos as opções que sejam da necessidade naquele momento de iniciar o recurso (novamente, não se preocupe, pois a classe de e-mail será vista em momento futuro).

Apelido

O terceiro parâmetro (opcional) é o apelido que podemos atribuir àquela classe para seu uso durante a programação. Por exemplo, é possível fazer o seguinte:

$this->load->library('email', '', 'em');
$this->em->to('fulano.de.tal@exemplo.com.br');

Obviamente este apelido de exemplo não tem nenhuma utilidade prática e serviu somente para exemplificar o uso do recurso. Em projetos “de verdade”, provavelmente não será preciso atribuir apelidos aos recursos básicos do CI.

Auto carregar libraries no CodeIgniter

É bastante comum um projeto usar diversos recursos nativos do CodeIgniter. Se esse for o caso, imagine a inconveniência de carregar a biblioteca em cada controller… Felizmente, existe a possibilidade de autoload de libraries (de demais recursos) do CodeIgniter.

Basta acessar o arquivo application/config/autoload.php e procurar o array de recursos que se quer. No caso das libraries, que estamos tratando, basta encontrar a diretiva “libraries” (na versão atual, linha 55) e preencher o array com os nomes das bibliotecas que se queira. Por exemplo:

$autoload['libraries'] = array('database', 'session', 'email');

Com isso, estas bibliotecas serão automaticamente carregadas em cada chamada ao CI, dispensando e economizando o uso de um loader específico para cada recurso.

Palavras finais

Como pôde ser visto, carregar e usar recursos de uma library no CodeIgniter é bastante simples e, depois de certo tempo usando o framework, bastante intuitivo.

A atenção fica para 2 pontos: ao usar apelidos, não cometer o erro juvenil de dar nomes iguais para recursos diferentes e; analisar bem o recurso de autoload explicado, já que carregar recursos do CI para controllers que não farão uso deste é desperdiçar recursos e comprometer a performance do projeto.

Estrutura de diretórios do CodeIgniter 2

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 CodeIgniter 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 2

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

Diretórios

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

• 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.
• system. Local destinado aos arquivos que fazem o CodeIgniter o que é; são os arquivos do core. Geralmente, não devem ser mexidos.
• 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), dentre outras muitas configurações
• 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.

application

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

• cache. Pasta usada quando se está usando caching no CodeIgniter. É aqui que as páginas cacheadas ficam armazenadas e são servidas.
• 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.
• core. Pasta criada no CI 2 para conter algumas bibliotecas consideradas mais “core” que outras. Não é usada em todos os projetos.
• 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.
• logs. Quando se habilita o salvamento de logs em arquivo em /application/config/config.php, é nesta pasta que eles serão salvos.
• migrations. Quando se usa acesso externo ao CodeIgniter via linha de comando (CLI), a pasta “migrations” é usada para algumas operações.
• models. Armazena os models que você cria para seu aplicativo.
• third_party. É possível distribuir aplicativos inteiros do CodeIgniter de forma fácil, e, para tal, é possível criar estrutura personalizadas nesta pasta, onde constam todos helpers, liberaries, models, etc, destas aplicações.
• 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 “application”, criando arquivos nos diretórios adequados – conforme foi abordado neste artigo – e somente criar/alterar arquivos de “system” caso você saiba exatamente o que está fazendo (e tenha um bom motivo pra isso).

E fazem parte dessa estrutura as classes. Grande parte do poder do CodeIgniter se dá devido a suas classes e o que se pode fazer com elas. Veja que classes são essas e um resumo sobre o que cada uma pode fazer.

Classes do CodeIgniter: apresentação e resumo

• Benchmarking Class. A classe de benchmarking permite “marcar” pontos no código, fazer comparações sobre tempos de execução diferentes e até saber quanto de memória está sendo gasta para rodar a aplicação.
• Calendar Class. Com esta classe é possível criar calendários dinâmicos. Criar o layout dos calendários e inserir dados dinâmicos é tarefa simples com esta classe.
• Cart Class. A classe de carrinho de compras tem todo o básico que envolve processo de e-commerce: adicionar itens ao carrinho, atualizar, deletar, mostrar o preço, etc.
• Config Class. Serve para mostrar as opções de configuração do CodeIgniter, tanto as default (/application/config/config.php), quanto as em arquivos personalizados.
• Email Class. Como sugere o próprio nome, esta é para envio de e-mails. Com extrema facilidade é possível adicionar endereços, CC, CCO, anexar arquivos e muito mais.
• Encryption Class. Se o problema é gerar strings encriptadas, então ele acabou. Com a classe de encriptação, as tarefas de encriptar, descriptar e correlacionados são bem mais simples.
• File Uploading Class. Com uma vasta gama de opções, fazer upload no CodeIgniter é a uma das coisas mais fáceis quando se usa a classe para upload de arquivos.
• Form Validation Class. Uma boa validação também deve ser feita no back-end; para tanto, o CI conta com muitas e diversificadas opções de validação para formulários.
• FTP Class. Classe para fazer as operações FTP tradicionais, como transferências, mover arquivos, renomear, apagar, etc.
• HTML Table Class. Classe que permite gerar tabelas dinâmicas a partir de resultados de arrays e/ou consultas a bancos de dados.
• Image Manipulation Class. Uma das mais incríveis classes do CI, permite fazer alterações em images como redimensionar, rotacionar, criar miniaturas, inserir marcas d’água, dentre outros.
• Input Class. Tem dupla finalidade: pré-processar dados de inputs (questões de segurança) e funções para manipulação/verificação de dados via input.
• Javascript Class. Classe que, usando funções javascript, provê algumas funcionalidades e efeitos básicos do jQuery, como hide/show, fadeIn/fadeOut, animation e outros.
• Loader Class. É a classe do CodeIgniter para carregar recursos diversos do framework, como libraries, views, helpers e models.
• Language Class. Classe que tem por objteivo prover suporte a internationalization.
• Output Class. Classe que, juntamente com recursos de cache, tem a finalidade de enviar a web page requerida completa.
• Pagination Class. Classe muitos fácil de se usar que permite fazer paginações em quaisquer conjuntos de resultados (muitas opções inclusas).
• Security Class. Como sugere o próprio nome, a Security Class provê funções para tratar da segurança da aplicação feita em CodeIgniter.
• Session Class. Classe para manipulação de sessões com o CodeIgniter (não são as sessões nativas do PHP).
• Trackback Class. Esta classe permite que se trabalhe com envio e recebimento de informações de trackback.
• Template Parser Class. Permite utilizar pseudo-variáveis nas views, de modo a simplificar a separação HTML/PHP.
• Typography Class. Esta classe provê funções para formatação de textos.
• Unit Testing Class. Classe para se mexer com Unit Testing (conta com funções simples, mas possui várias opções).
• URI Class. Essencial para se trabalhar com CI, esta classe serve para se trabalhar com informações contidas em URLs.
• User Agent Class. Permite saber informações sobre o “agente” que acessa a aplicação web (browser, dispositivo mobile, robô de busca). Possui diversas opções interessantes.
• XML-RPC Class. Como consta no nome, esta classe serve para tarefas envolvendo XML-RPC.
• Zip Encoding Class. Permite tarefas com arquivos compactados (.zip), tais como criação, adição/deleção de arquivos e até disponibilizar arquivos para download (forçado ou não).

Classes do CodeIgniter: conclusão

Como se pode ver, existem dezenas de classes no CodeIgniter para prover funções e funcionalidades prontas, que são de fácil manipulação e têm simplicidade de uso (pelo menos, a maioria delas).

Com o advento do CodeIgniter 2, algumas novas classes foram inseridas e, certamente, com as futuras versões, muitas outras ainda serão e as atuais serão modificadas, sempre no intuito de melhorar/facilitar ainda mais seu uso e interações.

É o CodeIgniter, mais uma vez, mostrando que é o melhor framework PHP!

O relacionamento padrão entre uma URL e um Controller no CodeIgniter segue a estrutura exemplo.com/classe/metodo/id/ (como mostrado no artigo sobre Controllers no CodeIgniter), mas, às vezes, é preciso “remapear” este relacionamento. No CodeIgniter, isso é feito através de routes (rotas).

Tomemos como exemplo a visualização de produtos em uma loja virtual. Digamos que a página para visualização dos detalhes de uma cadeira de balanço seja acessada através da URL minhaloja.com/produtos/detalhes/1/2 onde “produtos” é nosso controller; “detalhes” é a função que exibe os detalhes do produto; “1″ seja o código da categoria cadeiras; e “2″ seja o código de nossa cadeira de balanço. Esta estrutura funciona perfeitamente, mas, convenhamos, não é “elegante”.

Configuração de rotas

A configuração de rotas é feita através do arquivo /application/config/routes.php, na instalação padrão do CodeIgniter. Alguns exemplos de configuração de routes:

1
2
3
4
5
6

// "minhaloja.com/fale-conosco" vai direcionar para o controller "contato"
$route['fale-conosco'] = "contato";
 
// "minhaloja.com/fale-conosco" vai direcionar para o controller "cadastros"
// utilizando a função "novo_cliente"
$route['cadastro/clientes'] = "cadastros/novo_cliente";

Wildcards ou Curingas

Você pode usar curingas (wildcards) para configurar rotas. Desta forma, é possível deixar as URLs mais dinâmicas. Existem 2 tipos de wildcards:

1. :num. O wildcard “:num”, utilizado para rotear somente números.
2. :any. O curinga “:any”, utilizado para rotear qualquer caractere.

Voltando ao exemplo anterior, que tal transformar a URL “minhaloja.com/produtos/detalhes/1/2″ em “minhaloja.com/1/2/”? Seguindo a estrutura padrão do CodeIgniter, pressupõe-se que se está chamando o controller “1″ e, dentro do controller, a função “2″, o que não existe na prática.

Para resolver o problema, vamos escrever a seguinte rota:

1

$route[':num/:num'] = "produtos/detalhes";

Dessa forma, haverá direcionamento para “produtos/detalhes” sempre que os seguimentos 1 e 2 da URL sejam numéricos.

Exemplo da função detalhes dentro do controller “produtos”:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class Produtos extends CI_Controller
{
    function __construct()
    {
        parent::__construct();	
    }
 
    function index()
    {
        // Função index é acessada quando não for passada nenhuma função para o controller
    }
 
    function detalhes()
    {
        echo $this->uri->segment(1); // retorna o código da categoria
        echo $this->uri->segment(2); // retorna o código do produto
    }
}

Rotas com expressões regulares

É possível utilizar expressões regulares para definir as rotas no CodeIgniter. Vamos reescrever a rota do nosso exemplo:

1

$route['(:num)/(:num)'] = "produtos/detalhes/$1/$2";

Agora, o controller fica assim:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

class Produtos extends CI_Controller
{
    function __construct()
    {
        parent::__construct();	
    }
 
    function index()
    {
        // Função index é acessada quando não for passada nenhuma função para o controller
    }
 
    function detalhes($id_categoria, $id_produto)
    {
        echo $id_categoria; // retorna o código da categoria
        echo $id_produto; // retorna o código do produto
    }
}

Rotas e SEO

A URL minhaloja.com/1/2/ ficou bem mais curta e elegante, mas não é amigável quando vamos falar de SEO. É muito melhor ter uma estrutura como:

http://minhaloja.com/cadeiras/cadeira-de-balanco/

Esta URL é “amigável” para os motores de busca e, se você tiver, por exemplo, um campo no cadastro de produtos da loja para armazenar o nome da categoria e uma “descrição de URL” (slug) do produto – como “cadeira-de-balanco” -, fica muito fácil. Essa técnica é comumente chamada de URLs amigáveis.

A regra do exemplo é:

1

$route['(:any)/(:any)'] = "produtos/detalhes/$1/$2";

O controller permanece inalterado; só é preciso buscar no banco de dados os produtos com base nos slugs de categoria e produto – caso não saiba como criar slugs, confira o artigo “URLs amigáveis (slug) à WordPress“, do blog desenvolvimento para web.

Rotas reservadas

Existem um wildcard reservado no CodeIgniter: “welcome”. Ou seja, você não poderá utilizar a seguinte rota em seus projetos:

1

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

Conclusão

Rotas servem para alterar o relacionamento padrão entre uma URL e um Controller no CodeIgniter. Sabendo utilizar bem os tipos de rotas disponíveis, é possível criar estruturas incríveis, que realmente facilitam o desenvolvimento e acesso a controllers e funções – e o SEO agradece!

Com estas dicas já é possível configurar suas rotas e melhorar a navegação em seus projetos com CodeIgniter.

Espero que tenham gostado deste meu primeiro artigo no CodeIgniter Brasil e fiquem ligados para mais novidades!

No artigo sobre instalação e configuração inicial do CodeIgniter, consta que um dos passos é configurar o arquivo próprio para especificar as informações de BD. Apesar de o arquivo ser todo comentado e estruturado de maneira simples, é possível elucidar ainda mais com um artigo explicando como é a configuração de banco de dados (database) no CodeIgniter.

database.php

As configurações de banco de dados no CodeIgniter é feita através do arquivo application/config/database.php. As configurações são armazenadas em um array multidimensional que segue o seguinte padrão:

$db['default']['hostname'] = "localhost";
$db['default']['username'] = "root";
$db['default']['password'] = "";
$db['default']['database'] = "database_name";
$db['default']['dbdriver'] = "mysql";
$db['default']['dbprefix'] = "";
$db['default']['pconnect'] = TRUE;
$db['default']['db_debug'] = FALSE;
$db['default']['cache_on'] = FALSE;
$db['default']['cachedir'] = "";
$db['default']['char_set'] = "utf8";
$db['default']['dbcollat'] = "utf8_general_ci";

Existe um motivo principal para essas informações serem armazenadas em um array multidimensional: a facilidade do CodeIgniter chega a tal ponto que trabalhar com múltiplos bancos de dados é, literalmente, tão simples quanto montar um array, ou seja, se for preciso trabalhar com vários BDs (um para produção, outro para testes, mais um para homologação, etc), basta criar mais um array com as respectivas informações!

Se, por exemplo, além das configurações “default”, fosse preciso trabalhar com um banco de testes, algo do tipo poderia ser feito:

$db['teste']['hostname'] = "localhost";
$db['teste']['username'] = "root";
$db['teste']['password'] = "123456";
$db['teste']['database'] = "database_name";
$db['teste']['dbdriver'] = "mysql";
$db['teste']['dbprefix'] = "";
$db['teste']['pconnect'] = TRUE;
$db['teste']['db_debug'] = FALSE;
$db['teste']['cache_on'] = FALSE;
$db['teste']['cachedir'] = "";
$db['teste']['char_set'] = "utf8";
$db['teste']['dbcollat'] = "utf8_general_ci";

Então, a variável $active_group permite escolher os grupos de conexão que estarão ativos – por padrão, somente o “default” está ativo.

Explicação dos valores

Como é possível ver, existem diversos valores no array, cada um prestando a servir determinada funcionalidade nas configurações de bancos de dados:

• hostname. O hostname para a conexão (costuma ser “localhost”).
• username. O nome de usuário usado para a conexão ao BD.
• password. A senha necessária para se conectar ao banco.
• database. O nome do banco de dados que se deseja conectar.
• dbdriver. O tipo de banco de dados (mysql, postgres, odbc, etc).
• dbprefix. Um parâmetro (opcional) que especifica prefixo para as tabelas. Especialmente útil quando se usa Active Records (que será explicado futuramente), permitindo múltiplas instalações do CI usarem um mesmo database.
• pconnect. TRUE ou FALSE, especifica se vai ser usado persistent connection no projeto.
• db_debug. TRUE ou FALSE, serve para mostrar ou não os erros de queries que possam vir a ocorrer.
• cache_on. TRUE ou FALSE, marca se o database query caching (abordado em artigos futuros) será usado.
• cachedir. Quando se usa o database query caching, é o caminho para o diretório de cache.
• char_set. O character set usado para as comunicações com o banco.
• dbcollat. O collation usado para se comunicar com o BD.
• port. Opção usada somente com Postgres driver. Para usar a configuração, é necessário acrescentar mais uma linha ao array de configuração do database (ex. $db['default']['port'] = 5432;).

Palavras finais sobre configuração de bancos de dados

Dependendo da plataforma de banco de dados você está usando (MySQL, Postgres, etc), nem todos os valores do array de configuração serão necessários. Por exemplo, se estiver usando SQLite você não precisará fornecer um nome de usuário ou senha, e o nome do banco de dados será o caminho para o arquivo de banco de dados. Por padrão (e os exemplos apresentados) foram conforme o que se usa para bancos MySQL.

Reforçando ainda mais o fato de que o CodeIgniter é o melhor framework PHP, configurar um ou mais bancos de dados é tão simples quanto escrever algumas breves linhas de códigos. Somando este conhecimento ao básico sobre models e como fazer models, views e controllers trabalharem juntos no CodeIgniter, já é possível esboçar os primeiros “projetos de verdade”!

Vamos lá? ;-)

Já vimos no CodeIgniter Brasil artigos sobre Models, Views e Controllers, separadamente. Para projetos “da vida real”, no entanto, todos estes trabalham conjuntamente e é preciso “juntar as peças” para entender como se dá este funcionamento. Neste artigo, apesar de ainda não ser um projeto “oficial”, veremos como fazer Models, Views e Controllers trabalharem juntos no CodeIgniter!

O Model

Vamos supor que existe um banco de dados de um sistema de blog feito em CI. Vamos supor, ainda que uma das funções desse model, “Blog_model”, serve para pegar “N” registros do BD para se exibir onde se queira. Seria algo como:

1
2
3
4
5

function get_posts($n)
{
    $query = $this->db->query('SELECT title, content, slug FROM posts LIMIT ' . $n);
    return $query->result();
}

Obviamente este seria somente um fragmento de códigos. Se estiver com dúvidas, vide o artigo sobre Models no CodeIgniter.

O Controller

Nosso controller, “Blog”, dentre outras coisas, possui uma função para se valer do respectivo model:

1
2
3
4
5
6
7
8

function index()
{
    $this->load->model('Blog_model');    	
    $data['title'] = 'Blog de Testes do CodeIgniter';
    $data['posts'] = $this->Blog_model->get_posts(5);
 
    $this->load->view('blog_index', $data);
}

Como vimos no artigo sobre Controllers no CodeIgniter, é possível passar dados a views por um array ou objeto no segundo parâmetro da função de carregar o view.

O View

No view, tratamos os valores do array passado como se fossem variáveis “comuns”. No caso de $posts, já que um conjunto de dados virá do BD, realizar um foreach, conforme explicado no artigo sobre Views no CodeIgniter.

1
2
3
4
5
6

<h1><?php echo $title ?></h1>
 
<?php foreach($posts as $p): ?>
    <h1><a href="/blog/<?php echo $p->slug ?>"><?php echo $p->title ?></a></h1>
    <?php echo $p->content ?>
<?php endforeach ?>

Conclusão

A conclusão é que é muito fácil trabalhar com CodeIgniter (e olha que nem começamos a apresentar as classes e libraries nativos)! Viram como separando o contato com o banco de dados (model), a lógica (controller) e a apresentação (view) é muito mais simples e organizado de se programar?

A separação que o MVC proporciona é incrível e confere uma também incrível facilidade de se manutenir, em separado cada uma das “partes” que constituem o site, software, sistema online ou o que quer que se faça usando CodeIgniter!

É por isso que não cansamos de repetir que o CodeIgniter é o melhor framework PHP!

Relembrando nossa saga de explicações básicas, vimos como é o funcionamento do padrão MVC, os controllers (e como funciona o esquema de URLs no Codeigniter em função dos controllers) e models. Chegou, então, o momento de estudarmos um pouco sobre  views no CodeIgniter!

Views no CodeIgniter

Como foi mostrado no referido artigo sobre Model – View – Controller,

View é a apresentação, é o que aparece, é o que é visualizado por quem usa o sistema. É no View que as informações, sejam elas quais forem e de de qual lugar tenha vindo, são exibida.

No artigo sobre controllers, foi dado o exemplo de uma função matemática que, conforme o URL passado, soma 2 números e exibe o resultado em tela através da função echo(). Mas o exemplo foi somente para ilustrar como é o funcionamento geral dos controllers. Na prática, tudo o que se vai mostrar a quem utiliza o site/software deve ser feito através de views!

Afinal de contas, o padrão MVC foi criado para, justamente, manter em “compartimentos separados” a lógica do aplicativo, o contato com os dados usados e a exibição de o que quer que seja a quem o utiliza. Portanto, views foram idealizados para exibirem todas as informações/processamento que ocorra entre models-controllers. Reforçando: tudo deve ser exibido através de views!

Para ficar claro, podemos dizer que as principais funções de um view, através de invocações de métodos e ventos, são:

• “Renderizar” (exibir) informações vindas dos models/controllers;
• Requisitar atualizações aos models/controllers;
• Enviar ações de usuários (através de inputs) a models/controllers;

Cada vez mais é possível observar a eficiência e praticidade do padrão MVC e perceber que cada um preciso e trabalha em conjunto ao outro. Models, Views e Controllers, cada um tem uma razão de existir e desempenha um papel diferentes, todos em conjunto para viabilizar um desenvolvimento eficiente e organizado.

Funcionamento de Views no CodeIgniter

Seguindo a “linha” dos outros artigos, este tópico deveria ser “Estrutura de um View no CodeIgniter”, mas os views são formados simplesmente por XHTML e CSS. Views são a parte que é vista pelos visitantes/usuários, e, na web, isso é desenvolvido e apresentado usando as respectivas linguagem de marcação e folhas de estilo. Então, views podem ser uma página completa ou um fragmento de uma página, como um cabeçalho, um rodapé, uma barra lateral e assim por diante.

Vamos, então, passar a alguns pontos referentes ao funcionamento de views no CodeIgniter.

Armazenamento de Views

Os views devem ser armazenados em application/views. Simplesmente dê um nome a seu view e armazene neste diretório – muitos views são diretamente ligados a um controller; sendo este o caso, ou não, é importante dar nomes aos views que remetam facilmente a qual função ou conjunto de funções ele está refere. Por exemplo: application/views/about.php

Também é possível estruturar e refinar mais a organização de views. O CodeIgniter permite que se criem subníveis de diretórios dentro do diretório padrão de views. Então, por exemplo, é possível armazenar arquivos de views em uma estrutura do tipo: application/views/includes/head.php ou application/views/blog/widgets/advertising.php.

Carregando um(a) view

Para carregar um(a) view em um controller:

1

$this->load->view('about'); // sem extensão, se for ".php"

Para o caso de organização em subdiretórios, basta especificar onde o view se encontra:

1

$this->load->view('includes/head.php');

Carregando múltiplos views

Para carregar múltiplos views, basta chamar um por linha e o CI faz a “montagem” em uma só exibição:

1
2
3

$this->load->view('includes/head');
$this->load->view('body');
$this->load->view('includes/footer');

Passando informações para views

É possível entender o poder do CodeIgniter e sua facilidade de uso ao se passar uma informação dinâmica para ser exibida em um view! Basta carregarmos essa informação em um array ou objeto e passar essa informação no momento de carregamento do view no controller. Por exemplo:

1
2
3
4
5
6

$data = array(
    'title'   => 'Sobre',
    'content' => 'Texto da página sobre',
);
 
$this->load->view('about', $data);

Nisso, as informações do array $data serão passadas ao view. Para exibir essas informações na view, simplesmente é preciso tratar como se cada um dos itens do array fosse uma variável à parte, da seguinte maneira:

1
2

<h1><?php echo $title ?></h1>
<p><?php echo $content ?></p>

Fazendo loopings nos views

Para fazer loopings em views, também é simples. Por exemplo, vamos supor que tenhamos carregado a seguinte informação em um controller:

1
2
3
4
5

$data['todo_list'] = array('Lavar os pratos', 'Limpar a casa', 'Ligar para a pizzaria');
 
$data['title'] = "Lista de afazeres";
 
$this->load->view('afazeres', $data);

Então, no respectivo view, teríamos:

1
2
3
4
5
6
7

<h1><?php echo $title ?></h1>
 
<ul>
    <?php foreach($todo_list as $item): ?>
        <li><?php echo $item ?></li>
    <?php endforeach ?>
</ul>

Existe, ainda, uma maneira de passar o “data” para os views como string puro. Mas, como isso não é tão comum de ser feito, fica para um próximo artigo, mais específico.

Conclusão sobre Views no CodeIgniter

Obviamente isso não é tudo o que se tem para saber sobre views no CodeIgniter. Mas esse “básico” sobre views, juntamente com o conteúdo sobre models e controllers, já passa uma noção bem legal sobre o poder do CodeIgniter.

Para quem não conseguiu juntar as peças sobre MVC no CodeIgniter, não se preocupe: no próximo artigo vamos colocar models, views e controllers para trabalhar juntos e você vai ver um dos motivos de porque o CodeIgniter é o melhor framework PHP! ;-)

Já vimos que Controllers no CodeIgniter são responsáveis por controlar o fluxo dos programas, que contêm as regras de negócio. Já no artigo sobre MVC, também vimos que Models no CodeIgniter são responsáveis pelas quais o CRUD acontece, ou seja, sempre que dados forem criados, selecionados, atualizados ou deletados, seja num banco de dados, arquivo XML ou onde quer que estes dados estejam armazenados, então é com o Modelque temos que trabalhar.

Models do CodeIgniter

É possível, sim, desenvolver sites com CodeIgniter trabalhando somente com Controllers e Views; entretanto, este seria um uso “castrado” do framework, já que muito de seu poder reside na capacidade de abstração e tratamento de informações vindas de bancos de dados. Explicava a devida importância dos Models no CodeIgniter, vamos aprender um pouco mais a respeito.

Ao limitarmos nosso desenvolvimento a somente projetos “estáticos”, sem o poderoso recurso de armazenagem de dados, na verdade não conseguiremos desenvolver grandes feitos quando o assunto é internet. Realmente existem nichos de atuação para captação de recursos que dispensam uso de BDs, mas o foco de atuação deste blog não é este.

Então, regra geral, sempre que pensarmos em CodeIgniter, devemos pensar em uso de bancos de dados para armazenagem das informações, seja na feitura de um blog, site, e-commerce ou qualquer outro sistema online.

Foi visto no artigo sobre MVC que os Models possuem as seguintes características principais:

• Encapsula o estado da aplicação;
• Realiza e responde a consultas no banco de dados.

Estrutura de um Model no CodeIgniter

Models no CodeIgniter ficam armazenados em application/models, aceitando, também, estruturação em subdiretórios, caso seja preciso.

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 model no CodeIgniter (para fins didáticos, “Blog”) é a seguinte:

1
2
3
4
5
6

class Blog extends CI_Model {
    function __construct()
    {
        parent::__construct();
    }
}

E, a partir dessa estrutura-modelo, deduz-se as seguintes regras de sintaxe:

• Nomes de classes de models devem ter a primeira letra em maiúsculo;
• Nomes de classes de models, com exceção da primeira letra, devem ser em minúsculo;
• Os models devem extender a classe base “Model” através de uma função com mesmo nome da classe;
• O arquivo da classe deve ter o mesmo nome da classe em minúsculo (ex., application/models/blog.php).

Carregando um Model

Comumente, models são carregados a partir de funções nos controllers do software. Genericamente, um model é carregado através da seguinte função:

1
2
3

 // se o arquivo do model estiver em subdiretório,
 // basta indicar o caminho no parâmetro
$this->load->model('Model');

Depois de carregado o model, suas funções são acessadas a partir da seguinte sintaxe:

1

$this->Model->function();

Opcionalmente, é possível especificar um “apelido” para um model, apelido este que, se especificado será usado para a chamada das funções:

1
2

$this->load->model('Model', 'apelido');
$this->apelido->function();

Carregar models automaticamente (auto-loading Models)

É bastante comum um model ser tão útil ao ponto de precisar ser usado em praticamente toda uma aplicação. Para esses e outros casos, o CodeIgniter permite que um ou mais models sejam carregados automaticamente, juntamente com a inicialização do sistema.

Para carregar models automaticamente, abra o arquivo application/config/autoload.php, procure a seção “Auto-load Models” e especifique no array qual(is) model(s) você deseja que sejam carregados automaticamente. Por exemplo:

1

$autoload['model'] = array('blog', 'forum', 'chat');

Conectando ao Banco de Dados

Quando um model é carregado, não há conexão automática ao banco de dados. Isso é algo que deve ficar bem claro, pois gera enorme dúvida e, se não observado, pode parecer que está acontecendo um erro na lógica do programa – consequentemente, tem o potencial de fazer você desperdiçar horas de esforço atrás de um erro inexistente…

Existem diversos métodos de conexão ao banco de dados; para o momento, saiba que, para se conectar ao banco de dados de sua aplicação, você deve passar um parâmetro à função de carregamento do model. Fica assim:

1

$this->load->model('Model', '', TRUE); // parâmetro vazio é o "apelido"

Esse terceiro parâmetro indica que a conexão ao banco de dados deve ser feita utilizando as informações de BD contidas no arquivo application/config/database.php. Isso é o mais comum e prático de ser feito. Entretanto, há casos ou pode ser de sua preferência, especificar, no próprio controller, quais as informações necessárias para a conexão.

Nesse caso, ao invés de “TRUE”, o último parâmetro conterá o array (com nome de sua preferência) com esses dados:

1
2
3
4
5
6
7
8
9
10
11

// Os parâmetros mais "incomuns" serão explicados em artigos futuros
$config['hostname'] = 'localhost';
$config['username'] = 'username';
$config['password'] = 'password';
$config['database'] = 'database';
$config['dbdriver'] = 'mysql';
$config['dbprefix'] = '';
$config['pconnect'] = FALSE;
$config['db_debug'] = TRUE;
 
$this->load->model('Model', '', $config);

No próximo artigo serão explicados os diversos meios de o CodeIgniter se conectar a um (ou mais de um) bancos de dados. Não percam! ;-)

Já tivemos a oportunidade de ver a estrutura de diretórios do CodeIgniter, mas o objetivo foi apenas explicar a funcionalidade de cada pasta. Dando prosseguimento aos artigos introdutórios sobre CodeIgniter, vamos conhecer mais um pouco sobre alguns dos tipos de classes que podem ser usados no CI, quais sejam, helpers, libraries e plugins.

Um pouco de história

Existem diversos subdiretórios na pasta application e, conforme pode ser visto no livro CodeIgniter for Rapid PHP Application Development (na data de publicação deste artigo, ainda sem tradução para a Língua Portuguesa), nas versões do CodeIgniter anteriores à 1.5, a estrutura de diretórios era diferente. Rick Ellis, o carecão-mor, resolveu fazer alguns incrementos no framework, mas, por motivos de retrocompatibilidade, teve que manter algumas coisas como estavam.

Então, tecnicamente falando, não há maiores diferenças entre se valer de um helper, library ou plugin para implementar determinada funcionalidade no CodeIgniter. O que há são diferenças conceituais que podem, à primeira vista, parecer inúteis, mas, seguindo sua parte conceitual e atentando-se às convenções que a maioria dos usuários de CI fazem, são importantes de serem respeitadas.

Vamos ver as diferenças básicas entre uma helper, library e plugin (o que é algo que suscita bastante dúvida no princípio dos estudos de CI) para saber o momento certo de criar e usar e em qual pasta devemos nos preocupar em alocar os arquivos de desenvolvimento. Em artigos futuros, cada um vai ser abordado com mais detalhes, exemplos e práticas de uso.

Helper

Como sugere o próprio nome, helpers são para ajudar com as tarefas (não que libraries e plugins não sejam, mas quiseram dar esse nome, então está dado). Cada helper é um conjunto de funções relacionadas a uma determinada “categoria de tarefas”  – por exemplo, um helper nativo no CodeIgniter é o URL Helper, então, esse helper provê funções específicas para se trabalhar com URLs.

Helpers não são orientados a objetos (OO), são simplesmente programação procedural simples. Cada função de um helper executa uma tarefa específica, sem depender e sem causar dependência a outras funções do mesmo helper.

Como pôde ser visto em outra ocasião, é aconselhado que os arquivos de helpers estejam armazenados na pasta /application/helpers (não falando dos nativos, que já ficam em /helpers).

Library

Conceitualmente, uma library serve para conter seu próprio código para extender as funcionalidades do CodeIgniter (ou criar funcionalidades específicas para sites/softwares). Usualmente, quando um programador vai fazer sua própria classe, com funcionalidades específicas para o projeto, é uma library que é feita.

Como consta no artigo sobre a estrutura de diretórios do CodeIgniter, por padrão, os arquivos de bilbiotecas criadas ficam em /application/libraries e os nativos em /libraries.

Plugin

Plugins funcionam quase que da mesma forma que helpers. A principal diferença é que um plugin fornece, geralmente, uma única função, enquanto um helper, geralmente, apresenta várias funções. Outra diferença é que helpers também são considerados parte do “sistema principal”, ao passo que plugins se destinam a serem criados e compartilhados pela comunidade CodeIgniter.

Não se assuste caso sua instalação do CodeIgniter não tenha o diretório /application/plugins, isso é normal. Caso você queira se valer de um dos plugins da comunidade ou criar o seu próprio (para posterior compartilhamento), basta que você crie a subpasta “plugins” dentro de “application”.

Diferença prática entre helpers, libraries e plugins

Como já comentado, não há maiores diferenciações práticas entre um helper, uma library ou um plugin, dada a tamanha flexibilidade e capacidade de adaptação a gostos pessoais que o CodeIgniter apresenta. Com o tempo, vai se pegando “o jeito” do framework. e é possível saber/diferenciar onde cada classe, arquivo ou função deve ser criado, extendido ou ampliado.

Em artigos futuros serão abordados helpers, libraries e plugins com mais detalhes (assine o feed do CodeIgniter Brasil para não perder), mas, certamente, é programando e testando bastante que você vai conhecer as melhores práticas e “manhas” do 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 CI_Controller {
 
    function __construct()
    {
        parent::__construct();
    }
 
    public function index()
    {
        echo 'Olá, mundo!';
    }
 
    // demais funções
}

Perceba a sutileza: o método construtor é o que inicia a classe; o index() é o que é chamado por default, caso nenhum outro o seja.

O nome da classe deve iniciar com letra maiúscula

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

class Noticias extends CI_Controller {
}

Isso é errado:

class noticias extends CI_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
8

class Matematica extends CI_Controller {
    function __construct()
    {
        parent::__construct();
    }
 
    [...]
}

Sempre “parent::__construct();” 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
8

class Matematica extends CI_Controller {
    [...]
 
    public 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:

private 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 base sobre controllers 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 tópico do fórum oficial 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 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).

Baixando o CodeIgniter

Como já deve ser do conhecimento de quem está acompanhando o blog (se você ainda não está, assine o feed do CodeIgniter Brasil), o CodeIgniter, como bom framework PHP que é, não necessita ser instalado da forma “tradicional”, como se instala um programa desktop, por exemplo. Sua instalação consiste, basicamente, em extrair os arquivos que compõem o framework em algum servidor web (pode ser local, mesmo), configurar um banco de dados e começar a brincadeira.

No site oficial do CodeIgniter podemos encontrar o link para fazer o download da última versão do CodeIgniter. Não precisa se preocupar com o link porque sempre que uma nova versão estável é disponibilizada, ela automaticamente fica acessível através do endereço “http://codeigniter.com/download.php”. Bem prático!

Ah, e não se esqueça de já reservar um banco de dados especialmente para você trabalhar com o CodeIgniter! Já, já, você vai ver que, só para começar, é preciso configurar as informações de acesso ao BD.

Instalação  do CodeIgniter

Em alguns momentos para a instalação básica do CodeIgniter será preciso alterar algumas variáveis em arquivos específicos. Apesar do tamanho dos arquivos e relativa complexidade, não é preciso se preocupar. Além de os core files do CodeIgniter serem muito bem comentados, ainda abordaremos no CodeIgniter Brasil muito sobre os arquivos de configuração. Portanto, relaxe!  ;-)

Para instalar o CodeIgniter, basta seguir os seguintes passos:

• Descompacte a estrutura de diretórios presente no arquivo zipado que você baixou;
• Faça upload de toda a estrutura para o servidor que vai trabalhar (se for trabalhar com localhost, basta mover, claro);
• Abra o arquivo application/config/config.php com seu editor de códigos e especifique qual vai ser sua URL base (alterando o valor de $config['base_url'] com o que vai ser sua “base” de trabalho com o CI);
• Para a configuração do banco de dados, abra application/config/database.php e altere as variáveis com suas informações de conexão – é bem simples e intuitivo; se você fez uma conexão em PHP puro alguma vez na sua vida, nenhuma novidade.

E é isso! A essa altura seu CodeIgniter já está instalado, basicamente configurado e pronto para o uso!

Atualizando o CodeIgniter

Para saber qual a versão mais atual do CodeIgniter, basta checar o site oficial do CodeIgniter. Se você já mexe com CodeIgniter usando uma versão antiga e quer atualizar, não se preocupe: é possível manter a integridade de seu aplicativo e atualizar de forma rápida e simples o core do framework.

Há uma página com o histórico, especificações e intruções de atualização das várias versões do CI. Geralmente a atualização se limita a substituir algumas pastas e realizar alterações leves em alguns poucos arquivos. Então, já sabe: sempre que uma nova versão do CodeIgniter for liberada, não se esqueça de atualizar suas aplicações seguindo as instruções de “Upgrading From a Previous Version“.

É muito, muito importante, mesmo, entender como é o fluxo de dados dentro de um software para se poder aplicar os conhecimentos em cima. Entender por onde os dados “passam” no CodeIgniter é essencial! Sem isso o máximo que conseguiríamos e realizar algumas funções e códigos mecanicamente, sem entender o mínimo do que realmente está se passando no background.

Bem, esse é o fluxograma:

Fluxograma de Dados do CodeIgniter (clique para ampliar)

Olhando o fluxograma do CodeIgniter, num primeiro momento pode parecer um pouco estranho ou confuso. Mas, mesmo para os que ainda não estão habituados a frameworks e terminologias como “Libraries” e “Helpers” (e que ainda não tenhamos explicado sobre estes), basta “seguir as setinhas” para entender como a coisa toda funciona!  :-)

“Seguindo as setinhas”

Então, vamos ao acompanhamento de um fluxo básico, numa aplicação “normal” no CodeIgniter:

1. O index.php serve como “controlador principal”, inicializando os recursos necessários para executar o CodeIgniter;
2. O “roteador” (Routing) examina o pedido HTTP para determinar o que deve ser feito;
3. Se existe algo em cache, isso é enviado diretamente ao browser, “contornando” o sistema normal execução;
4. Antes de o Controller da aplicação ser carregado, a requisição HTTP e qualquer dado submetido pelo usuário são filtrados por motivo de segurança;
5. O Controller carrega o Model, Libraries, Plugins, Helpers e quaisquer outros recursos necessários para a requisição;
6. O(s) View(s) é(são) finalizado(s) e enviado(s) para ser(em) renderizado(s) pelo navegador – se o cache estiver ativado, o View é  “cacheado” primeiro, de forma que possa ser apresentado em pedidos subsequentes.

Como já citado, não é preciso se preocupar tanto (neste momento) com determinadas nomenclaturas desconhecidas – e lembre-se das explicações sobre MVC (Model, View, Controller). Basta saber que é assim o funcionando “normal” do CodeIgniter para, em momentos futuros, saber com mais facilidade/tranquilidade onde “intervir” para conseguir o(s) resultado(s) que se prentende.

Bem tranquilo… Por enquanto!  ;-)

Nossa escolha é CodeIgniter (CI) e abaixo estão as minhas 10 razões de porque CodeIgniter arrasa!

10. Arquitetura MVC

A arquitetura Model, View, Controller não tem nada de novo. É como se todos os frameworks hoje em dia fossem feitos em MVC e, os que não são, podem ser adaptados facilmente. Tenho tido experiência construindo grandes aplicações de forma procedural e toda vez elas terminam com uma salada-mista de códigos ingerenciáveis. A forma MVC oferece uma boa separação de códigos, e mantém a escrita limpa. Alguns frameworks forçam você a trabalhar de uma forma específica, mas o CI deixa você livre dentro do modelo MVC para programar como achar melhor. Se isso significa ignorar modelos, então, que assim seja.

9. Quase nenhum pré-requisito para o servidor

Diferente de outros frameworks PHP, o CI trabalha com as versões 4 e 5 do PHP. Isso faz a vida de alguém como eu, que tem que ser capaz de trabalhar entre as duas versões, muito mais fácil. Claro, há muito tempo tenho usado técnicas do PHP 5 nas minhas aplicações, mas o framework por si só funciona em ambas versões.

8. Fácil de entender e extender

O CI foi o primeiro framework que usei que realmente fez sentido para mim. Tentei o Cake PHP, o Zend Framework, Symfony, entre outros, e o CI foi o melhor para sair desenvolvendo rapidamente. É simples também quando se trata de escrever novas bibliotecas, mudar o comportamento de bibliotecas existentes, e simplesmente mudar todo comportamento do framework com um pequeno esforço.

7. Todas as ferramentas que você precisa em um pequeno pacote

Calendário, e-mail, codificação ZIP, validação, upload, sessões, teste de unidade… São somente algumas das bibliotecas pré-prontas que vêm com o CI. Isso inclui uma rápida importação dos “helpers” padrão para coisas como formulários, manipulação de arquivos, arrays, strings, cookies, diretórios e muito mais. Se tudo isso ainda não foi suficiente, você pode criar suas próprias bibliotecas e “helpers” ou usar código desenvolvido pela comunidade CI e postado no Wiki.

6. Instalação não necessária

Acredite ou não, uma das coisas mais difíceis que experienciei testando novos frameworks é a instalação dos mesmos. Eu não sou fã das linhas de comando UNIX, então procuro ferramentas que posso instalar e usar apenas subindo arquivos para um diretório. O CI é perfeito para isso. Não é preciso pacotes PEAR ou mudanças no servidor para ter o framework rodando. Apenas suba os arquivos para o seu servidor e pronto.

5. Ferramentas de segurança pré-prontas

O CI permite que você implemente quanta segurança for necessária para a sua aplicação. Ele faz algumas coisas por padrão como desconfigurar todas variáveis globais independente da diretiva register_globals do PHP, e desabilita o magic_quotes_runtime durante a inicialização do sistema, assim você não precisará remover as barras quando for capturar dados do seu banco de dados. Outras coisas podem ser habilitadas, como encriptação de cookies, integração de dados de sessão com o banco de dados e automação de tratamento de consultas SQL.

4. Abstração de banco de dados e mais

Todo framework decente de hoje em dia tem uma camada de abstração de banco de dados e o CI não é diferente. Você pode facilmente criar declarações de insert, update e delete sem precisar escrever SQL. Manipule conexões para múltiplos bancos dentro de uma só aplicação e conecte-se em qualquer tipo de banco: MySQL(4.1+), MySQLi, MS SQL, Postgre, Oracle, SQLite ou ODBC. O CI também deixa você manipular o banco de dados adicionando/removendo colunas de tabelas, criando novas tabelas e removendo as antigas usando a nova biblioteca “database forge”.

3. Comunidade grande e ativa

A ultima vez que chequei, havia mais de 57.000 (na data de publicação deste artigo, mais de 70000) membros registrados no fóruns CI. É uma ótima comunidade para trabalhar quando se tem um problema ou uma questão. O site do CI tem um fórum e um Wiki quando você procura por respostas. Não há listas de grupo confusas ou canais de chat apenas para pegar uma resposta rápida.

2. Documentação excelente

De longe, a maior vantagem do CI é sua documentação. Eu admito que tentei outros frameworks enquanto eles ainda estavam na versão BETA e sob desenvolvimento. Mas a documentação do CI é 10 vezes melhor do que a documentação deles, e realmente acredito que é porque o CI é apoiado por uma empresa e não somente pela comunidade. EllisLab, a empresa que criou o CI, tem orgulho de tê-lo criado e eles têm grandes planos para ele, de modo que eles não têm problema em gastar o tempo necessário para criar uma documentação de qualidade para a comunidade de usuários.

1. Logo mais irá se unificar com o ExpressionEngine

A primeira razão do porque o CI arrasa é que o ExpessionEngine, sistema de gerenciamento de conteúdo da EllisLab, está sendo reconstruído para utilizar o framework. Isso significa que as bibliotecas, “helpers”, etc. que você desenvolver para o CI, poderão ser reutilizados para o EE e vice-versa. Também significa que, o que quer que o EE precise operar, o CI tem. Classes melhoradas, autenticação de usuários pré-pronta, capacidade para facilmente programar aplicações modulares e muito mais. Tudo isso é apenas especulação, a nova versão do EE ainda não foi lançada, mas podemos sonhar (NT: quem tem uns dólares extra pode sonhar mais, porque o ExpressionEngine é pago).