Exatamente ontem surgiu num repositório fork do CodeIgniter uma novidade muito interessante: uma feature para compactar HTML! Apesar de não ser oficial, fiz alguns testes e está tudo funcionando muito bem! Portanto, compactar HTML no CodeIgniter agora é possível e, acredite, os resultados são incríveis!

Baixando a nova classe de Output

A primeira coisa a se fazer é substituir a classe nativa de Output do CodeIgniter pela que tem as modificações. Então, copie a Output Class modificada e coloque em /system/core (para os mais cautelosos, um backup é sempre bem-vindo).

Ativando a compactação de HTML

Assim como pode ser visto na pull request da compatação de HTML no CodeIgniter, a partir do momento em que a nova Output Class está presente, é preciso ativar a funcionalidade de compactar através de uma diretiva de configuração.

Por padrão, esta diretiva estaria presente em application/config/config.php, mas, como ela não existe, é preciso criá-la. Então, em qualquer ponto do arquivo config.php (ou outro arquivo de configuração que você esteja usando), inclua a seguinte diretiva:

$config['minify_output'] = TRUE;

E pronto! A partir de agora o CodeIgniter comprime toda e qualquer saída de HTML (e CSS inline) que passar pela Output (que, caso você esteja usando corretamente a abordagem MVC no CodeIgniter, significa a exibição nas views).

Conclusão sobre compactação de HTML no CodeIgniter

Apesar de (ainda) não ser um recurso oficial do CI e que, não há que se duvidar, ainda ganhará melhorias, realmente vale a pena, pelo menos, testar a compactação (embora já esteja estável o suficiente para ser usado em ambiente de produção).

<update>
Como esperado, as alterações na classe de Output já foram para o repositório oficial. O pessoal ainda está discutindo melhorias, portanto, fique ligado!
</update>

Claro que há muitos fatores a se considerar, mas estima-se que esta compactação reduza o tamanho da saída HTML em 10~15% (chegando, em alguns casos, a incríveis 30%), o que é bastante considerável! Com isso, a transferência de recursos no servidor e exibição de conteúdos, consequentemente, também ficam mais rápidos.

E tudo isso pode ficar ainda melhor quando se usa cache para os conteúdos! Mas isso já é assunto para outro artigo… ;-)

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! ;-)

A comunidade estava ansiosa por algumas mudanças e, como não é costume da Equipe CodeIgniter deixar seus fãs usuários na mão, eis que é lançado o CodeIgniter 2.1!

Boa tarde a todos! Finalmente após 3 meses da mudança do nosso querido CodeIgniter para o Github, foi anunciado hoje, pela EllisLab, o lançamento da versão 2.1.0 do CodeIgniter. Nesta versão foram adicionadas algumas grandes mudanças ao framework:

• Migrations. Para versionar também o banco de dados, através do Migrations, você simplesmente da um up() ou down().
• PDO Driver. Foi adicionado PDO como driver para os banco de dados, aumentando assim a gama de bancos suportados pelo CodeIgniter.
• Mais PHP5. Desde que foi “dropado” o suporte do CodeIgniter ao PHP4 aos poucos foi sendo mudada a sintaxe do core para o PHP5, e nesta versão mais coisa foi altearada para PHP5.

Estas foram as maiores mudanças, e também mais significativas desta versão. Para mais informações vejam no changelog.

A EllisLab também informou que todas mudanças (correções de bugs) que forem feitas na versão 2.1.x serão mescladas na versão 3.0 e todas novidades serão commitadas para o branch 3.0.

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.

É isso, mesmo, meus amigos: conforme tweet oficial, o CodeIgniter está sendo “relicenciado” para a Open Software License v. 3.0, também conhecida como OSL 3.0. A mudança não virá com a próxima versão, o CodeIgniter 2.1, e sim com a versão 3 do framework – CI 3; OSL 3… Entendeu? ;-)

No site da Open Source Initiative é possível acessar a página com os termos da OSL 3.0 para saber, juridicamente falado, quais os termos, deveres, obrigações e permissões que esta licença institui.

Na prática, o que muda?

Apesar de não ter formação jurídica, parece que o uso e desenvolvimento de sites, ferramentas e sistemas online do framework não foi alterado. Quer dizer, aparentemente, tudo o que consta no artigo sobre requisitos de servidor e licença de uso continua valendo (inclusive, na própria página da licença no User Guide, nada foi alterado).

Com a mudança para a OSL 3.0 a EllisLab, em termos gerais e em relação ao CodeIgniter, concede uma licença mundial, isenta de royalties, não exclusiva e sublicenciável de:

Mas, para saber na íntegra o que tudo isso significa, juridicamente falando (com todas suas aplicações, direitos e deveres), deem uma olhada na página com os termos da OSL 3.0.

Parece que esta licença veio para dar ainda mais liberdade para o uso do CI (com determinadas garantias e isenções para a EllisLab, evidentemente). Agora, resta esperar para maiores notícias sobre a mudança para vermos, efetivamente, o que mudou, não mudou e o que pode ou não pode ser feito com esta mudança de licença do CodeIgniter para a OSL 3.0 para saber as reais implicações na prática.

Enquanto isso, mais informações a respeito e discussões sobre a mudança podem ser acompanhadas no UserVoice do CodeIgniter e, no fórum oficial, no tópico “CodeIgniter changes license to OSL 3.0?“.

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!

Como os mais chegados no CodeIgniter já estavam sabendo, aconteceu recentemente a CodeIgntier Conference ou, como ficou mais conhecida, CICON. Infelizmente não deu para eu ir este ano e ajudar com o quórum de 100 codeigniters que lá estiveram… Quem sabe no próximo ano! ;-)

E, no CICON 2011, algumas coisas importantes a respeito do melhor framework PHP foram decididas (comunicado oficial), dentre as quais:

• “Core” e “Reactor”? Não mais… É isso, mesmo, não há mais os diferentes grupos “Core” e “Rector” para manter o framework. Devido a algumas reclamações da comunidade, agora voltamos ao bom e velho CodeIgniter, somente.
• Mudança para o Github. Agora o repositório oficial está hospedado no Github. Segundo os próprios engineers, essa será uma mudança que atenderá melhor às necessidades do projeto e anseios da comunidade.
• CodeIgniter 2.0.3. Saiu uma nova versão do CI! Veja no changelog o que mudou e, se vai fazer alguma diferença em algum projeto seu, atualize!

Segundo um dos principais engineers, Phil Sturgeon, o encontro foi bastante positivo, o pessoal gostou de se encontrar e bater um papo a respeito do CI e, inclusive, a base de contribuidores aumentou! Ele, e todos nós envolvidos com o projeto, esperamos que o CI continue crescendo!

Agora, vamos a algumas fotos do CICON 2011!

Quem sabe no próximo alguns brazilians codeigniters também aparece! ;-)

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.

Depois de alguns artigos aqui no CodeIgniter Brasil, algumas pessoas enviaram questões referentes à facilidade em se programar com CodeIgniter. É certo que cada um escolhe seu ambiente de desenvolvimento segundo seus próprios critérios, mas existem alguns que são realmente fantásticos para se trabalhar com PHP. É o caso do Eclipse PDT (PHP Development Tools), “ramificação” do Eclipse, um dos IDEs mais conhecidos e eficientes para programação.

Então, para o caso de você já usar o IDE, este tutorial vai ensinar como fazer autocomplete do CodeIgniter no Eclipse. Caso ainda não o conheça, dê uma pesquisada, baixe e teste o IDE que certamente você vai gostar. Não digo que esta deve ser a ferramenta definitiva para todas as necessidades, mas, certamente, é uma opção interessante a se considerar. Então, para entender as explicações, é preciso que você tenha tido, pelo menos, um mínimo de contato com o Eclipse PDT.

A lógica do autocomplete CodeIgniter + Eclipse

Por padrão, o Eclipse já faz autocomplete de classes e funções que você desenvolve em diferentes arquivos. Quando se trata de um projeto “comum”, é fácil para ele reconhecer e realizar o autocompletar. No entanto, para o CodeIgniter, em função da disposição peculiar de seus arquivos constituintes, devemos “ensinar” a ferramenta a reconhecer estas classes e funções.

O que é preciso para que o Eclipse faça o autocompletar do CodeIgniter é que ele, de alguma forma, tenha acesso e reconheça todas as classes e funções presentes no core do CI. A partir disso, ele será capaz de realizar o autocomplete dentro de qualquer controller e/ou model que você crie em seu projeto.

Basicamente, o que precisamos é:

• Criar 2 projetos no Eclipse: 1 com o CodeIgniter “puro”; outro com o CodeIgniter para o projeto, propriamente dito;
• Incluir, no CI “puro”, um pequeno trecho de código em 2 arquivos do code;
• No “Include Path” do projeto, propriamente dito, referenciar o projeto do CI “puro”;

Criando projetos no Eclipse

Baixe a versão mais recente do CodeIgniter. O download fornece um arquivo zipado. Na pasta de sua preferência, descompacte a estrutura 2 vezes: uma delas será nossa “base”, o outro, o projeto oficial. Chame, por exemplo, respectivamente, “CI_BASE” e “PROJETO”.

No Eclipse, crie 2 projetos, cada um apontando para uma pasta que foi gerada a partir da extração do CodeIgniter.

Tela mostrando os 2 projetos criados no Eclipse

Código-extra no “CI_BASE”

No projeto CI_BASE, você vai precisar alterar 2 arquivos de core:

Acrescente, em ambos, exatamente após o início do escopo da classe, o seguinte:

/**
 * @var CI_Config
 */
var $config;
 
/**
 * @var CI_DB_active_record
 */
var $db;
 
/**
 * @var CI_Email
 */
var $email;
 
/**
 * @var CI_Form_validation
 */
var $form_validation;
 
/**
 * @var CI_Input
 */
var $input;
 
/**
 * @var CI_Loader
 */
var $load;
 
/**
 * @var CI_Router
 */
var $router;
 
/**
 * @var CI_Session
 */
var $session;
 
/**
 * @var CI_Table
 */
var $table;
 
/**
 * @var CI_Unit_test
 */
var $unit;
 
/**
 * @var CI_URI
 */
 
var $uri;
 
/**
 * @var CI_Pagination
 */
var $pagination;

Atente-se em inserir o código nos lugares corretos.

Insira o código onde está a linha em destaque. O mesmo para /system/core/model.php.

Referenciando CI_BASE em PROJETO

Por fim, é preciso referenciar o projeto CI_BASE em PROJETO, a fim de que o autocomplete aparece neste. Para tanto, faça o seguinte:

• Clique o botão direito no projeto PROJETO e vá em Properties > PHP Include Path > aba Projects > botão Add…
• Selecione o check de CI_BASE > botão OK
• Confirme a ação clicando no botão OK

Include Path do projeto CI_BASE

A partir de agora, o autocomplete do CodeIgniter estará disponível em qualquer controller e model que você crie para seu projeto! Faça o teste e comprove: crie algum controller e tente usar, por exemplo, a função de carregar um view (já explicada no artigo sobre Views no CodeIgniter).

Exemplo de autocomplete do CodeIgniter no Eclipse

Conclusão

Na verdade, PROJETO continua sendo somente uma “instalação” do CodeIgniter. CI_BASE foi adicionado à lista de projetos somente para dar o suporte necessário ao autocomplete. Portanto, esta é uma técnica específica de prover o autocomplete do CodeIgniter no Eclipse, servindo para conferir maior comodidade, rapidez e eficiência para quem programa com CI neste incrível IDE.

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!

E, depois de muita espera, mudanças na estrutura de desenvolvimento, choro e ranger de dentes, eis que é lançado o CodeIgniter 2! É isso, mesmo, a equipe CodeIgniter Reactor oficialmente liberou o CodeIgniter 2 anteontem, dia 28 de janeiro de 2011!

Quem vem acompanhando as notícias do mundo CodeIgniter, não tem nada o que se surpreender com as novas features, que foram exaustivamente discutidas e “pré apresentadas” à comunidade. Mas, para quem ainda desconhece, algumas das principais mudanças/benefícios foram:

• Não há mais suporte a PHP4. Agora é a partir do PHP 5.1;
• Diretório “application” movido para a raiz;
• Diretórios “system/cache” e “system/logs” movidos para o diretório “application”
• Adicionado o prefixo “CI_” para todas as classes do core.
• O Form Helper agora conta com proteção CSRF;
• Drivers;
• Remoção do Scaffolding;
• Não existem mais plugins, em detrimento dos helpers;
• Mais de 50 bugs corrigidos;
• E muito mais!

Para ver a lista completa, veja o changelog do CodeIgniter.

Uma outra coisa que está para sair em breve é um sistema de comentários em cada página do User Guide, tal como existe hoje no site oficial do PHP. Dessa maneira, a documentação se tornará ainda mais rica com as contribuições, dicas e macetes dos membros da comunidade.

O jeito, agora, é baixar o CodeIgniter, fazer muitos testes e partir para o abraço com mais esta evolução do melhor framework PHP!

Por padrão, o CodeIgniter não suporta parâmetros $_GET; quando algo assim é identificado no URL, é automaticamente destruído pelo CI. Entretanto, pode haver situações em que é preciso pegar/passar variáveis com GET, seja por usar algum webservice, serviço de pagamento ou o que quer que seja.

Como o CodeIgniter é o melhor framework PHP, com ele também é possível liberar o acesso a parâmetros $_GET com muita facilidade. E mais: somente em controllers específicos!

Configurar o CodeIgniter para aceitar $_GET

A primeira coisa que deve ser feita é uma pequena alteração no arquivo /application/config/config.php. Localize a linha com a configuração “uri_protocol” e altere seu valor para “PATH_INFO“:

$config['uri_protocol'] =  'PATH_INFO';

Então, para cada método que seja preciso mexer com parâmetros GET, adicione o seguinte:

parse_str($_SERVER['QUERY_STRING'], $_GET);

A função parse_str do PHP simplesmente converte os parâmetros do URL em variáveis. Por exemplo:

$str = "framework=codeigniter&features[]=best+framework&features[]=rocks";
parse_str($str);
echo $framework;  // "codeigniter"
echo $features[0]; // "best framework"
echo $features[1]; // "rocks"

Obviamente a variável “str” do exemplo vai receber a URL-alvo (uma ajudinha sobre como pegar a URL atual) e, a partir daí, é possível trabalhar com variáveis comuns pra usar os parâmetros passados através de $_GET no CodeIgniter. Um exemplo de URL seria:

http://codeigniterbrasil.com/controller/metodo/?s=conteudo&c=codeigniter

Bem facinho, certo? Se alguém tiver alguma outra solução/dica sobre como usar GET no CodeIgniter e/ou pegar o URL atual, basta comentar!

Há algumas semanas, no CodeIgniter News, uma notícia chamou a atenção da comunidade: “The Official CodeIgniter Community Branch“. Neste “comunicado oficial” da EllisLab, foi informado que o CodeIgniter iria ser organizado em duas “ramificações”, uma “oficial” e outra mais da própria comunidade.

Alguns membros da comunidade CI ficaram alarmados e preocupados com o futuro do CodeIgniter, alguns chegando a especular que a notícia foi a sentença de morte do framework e outras opiniões de caráter duvidoso… Mas, na verdade, a proposta é somente uma (segundo os próprios mantenedores do CI): facilitar o desenvolvimento do CodeIgniter, tornando-o mais eficiente e de acordo aos anseios e necessidades da comunidade.

CodeIgniter Core e CodeIgniter Reactor

Então, mais recentemente, foram reveladas outras novidades sobre esta “ramificação”: a partir de agora, existe o CodeIgniter Reactor e CodeIgniter Core! Segundo a própria EllisLab, ambos focadas em oferecer um framework simples e poderoso através de acesso fácil, consumo mínimo de recursos e uma documentação de qualidade.

Embora ambas as “versões” continuem sendo de responsabilidade e petencentes à EllisLab, existem diferenças.

O CodeIgniter Reactor será guiada e mantida por 6 membros da comunidade CodeIgniter (eles foram eleitos através de um misto de voluntariado com análise de conhecimentos necessários), conhecidos, a partir de agora, como Reactor Engineers. Eles terão acesso e permissão de editar o CodeIgniter Reactor e contribuir livremente com códigos e documentação, tanto de si mesmos, como da comunidade, em geral. Para evitar discrepâncias ou alterações que podem causar erros e/ou instabilidades no framework PHP, os Engenheiros irão debater inclusões/alterações meticulosamente, com base num “acordo” sobre a filosofia do CodeIgniter.

CodeIgniter Core será exclusivamente mantido pela EllisLab e continuará com sua “tradição” de lançar versões sem pressa para poder testar exaustivamente os recursos novos ou editados – não deixando de lado sua “hiper crítica” ao incorporar código novo. A intenção é garantir que o CodeIgniter Core seja super estável e dê tranquilidade e segurança a quem o for utilizar, tendo em vista que existem muitos projetos realmente importantes que usam o CI, tais como aplicações web de nível empresarial, desenvolvimento em grande escala de empresas, projetos de instituições governamentais, etc.

Na prática, o que vai acontecer é que o CodeIgniter Reactor, depois de muita discussão entre os membros da comunidade e os Reactor Engineers, irá “despachar” as implementações que julgar necessárias para o CodeIgniter Core; será como um “pré-filtro”. Então, a “equipe de elite” vai julgar quais implementações serão oficialmente incorporadas e, depois de muitos, muitos testes, estas farão parte do Codeigniter Core.

CodeIgniter UserVoice

A fim de manter uma certa ordem no caos de pedidos e solicitações que a comunidade faz, alguém teve a ideia de criar um UserVoice para o CodeIgniter Reactor. Basicamente, o UserVoice permite as pessoas votarem em solicitações para saber quais os anseios mais “emergentes” da comunidade.

Paticipe, você, também, do UserVoice do Codeigniter Reactor!

CodeKindling

Existe, também, um projeto não-oficial, mas que tem uma proposta muita interessante, que é o CodeKindling. O CodeKindling tem a proposta de ter “recursos coletivos para a comunidade CodeIgniter”, ou seja, através do site, é possível submeter libraries, helpers, recursos em geral, ideias, feedback ou o que for, através de uma interface única.

O bom que é que você pode assinar uma espécie de newsletter e ser avisado sempre que novos recursos forem submetidos.

Conclusões sobre CodeIgniter Core e CodeIgniter Reactor

Muitas pessoas já manifestaram sua opinião (inclusive Phil Sturgeon, que é um dos Reactor Engineers (!), em seu artigo “EllisLab react with CodeIgniter Reactor“), e a minha é o seguinte: a comunidade gostando ou não, é assim que vai ser!

Não adianta ficar discutindo ou esbravejando com uma decisão “de cima”, da cúpula do CodeIgniter. Querendo ou não, aquele(s) que tomou(aram) esta decisão o fizeram depois de muito pensar e refletir, pois é assim que o mundo do business funciona. A EllisLab tem vários projetos comerciais (ela é uma empresa, certo?) diretamente ligados ao CodeIgniter, e isso certamente foi levado em consideração.

É quase certo, também, que os membros do CodeIgniter Reactor estão levando bons dólares “por fora”, afinal, eles tiveram que ser recrutados para o cargo, certo? Dependendo do seu ponto de vista, isso pode ser algo bom ou ruim…

O que podemos esperar é que esta “bifurcação” traga bons resultados à comunidade e que possamos continuar participando e sugerindo alterações e inserções no CI. Aparentemente é isso, mesmo, que está acontecendo e será reforçado, e isso é algo bom!

Agora é aguardar os resultados e desdobramentos dessa nova “fase” do CodeIgniter, sempre com o pensamento de que recursos cada vez melhores e mais fáceis de usar sejam lançados.

O futuro dirá.

PS: Phil Sturgeon fez um mirror da documentação oficial do CodeIgniter 2. Segundo o próprio, a versão já está muito estável, inclusive podendo ser usada para projetos oficiais.

Mas, além do MVC, existem uma abordagem diferente, considerada, por alguns, como uma evolução a esse consagrado padrão. Trata-se do Hierarquical Model-View-Controller (Model-View-Controller Hierárquico), mais conhecido como HMVC!

O CodeIgniter atualmente não apresenta suporte nativo ao padrão HMVC, portanto,, caso se queira usufruir de seus benefícios, é preciso se valer de códigos da comunidade. Neste artigo, ensinaremos como dar suporte ao HMVC no CodeIgniter usando o Modular Extensions.

Sobre o HMVC

O HMVC é tido como uma evolução do MVC. Basicamente, é como se a estrutura básica de funcionamento do CodeIgniter tivesse um nível hierárquico acima, “englobando” cada tríade MVC, tornando-a modular e, até certo ponto, independente das demais.

Em outras palavras: com HMVC é possível ter “pacotinhos” de models, views e controllers independentes, que funcionam separadamente de outros “pacotinhos”, mas que podem se comunicar com todos eles. É como mostra a seguinte imagem:

Estrutura HMVC no CodeIgniter

HMVC no CodeIgniter

A primeira coisa a se fazer para implementar o HMVC no CodeIgniter é fazer download do Modular Extensions. Depois de baixá-lo, você verá que existem 2 pastas no arquivo compactado: “core” e “third_party“. Proceda da seguinte maneira:

Pronto, agora você já tem uma estrutura HMVC no CodeIgniter!

Atenção para algo muito importante: ao implementar a estrutrura de HMVC no CodeIgniter com o Modular Extensions, você abre mão da estrutura tradicional do CI. A partir de agora, você deve criar subdiretórios dentro de “modules” com seus “pacotinhos” de tríades MVC. Ou seja, a partir de agora, os diretórios “models”, “views” e “controllers”, que ficam dentro da pasta “application”, não mais necessitam ser usados.

Por exemplo, vamos supor que você utilize uma tríade para exibição de livros de um site ou sistema virtual, qualquer. Neste caso, poderia usar uma estrutura como esta:

E, dentro dessa estrutura, mexer normalmente com os models, views e controllers. Em relação à estrutura de URLs, nada se altera; dentro do exemplo, se tivéssemos um controller “listar” dentro de application/modules/livros/controllers/, este seria acessado via (usando a técnica explicada no artigo Dicas básicas de configuração do CodeIgniter para retirar o segmento “index.php”):

http://www.site.com.br/livros/listar/

Quanto à configuração de $route['default_controller'] em application/config/routes.php, pode ficar tranquilo, já que, também, nada se altera: coloque o nome do controller e pronto.

Conclusão sobre HMVC no CodeIgniter

Talvez as maiores vantagens da abordagem HMVC sejam a praticidade e facilidade de reaproveitamento de códigos. Para o caso de um módulo desenvolvido precisar ser usado em outro projeto, simplesmente copie o módulo em questão e cole na nova instalação do CodeIgniter (provida de HMVC e mesma estrutura de banco de dados, obviamente) e pronto! Nada mais precisa ser feito!

Não é só porque o HMVC é considerado como uma “evolução” por alguns que seja preciso utilizá-lo em todo e qualquer projeto. Entretanto, a praticidade de se usar módulos prontos de outros projetos é notável e pode, sim, fazer a diferença num cumprimento de um prazo mais apertado! Se for o caso, não hesite em se valer da praticidade do padrão HMVC!

No início deste mês de setembro fui agraciado com um exemplar do livro “CodeIgniter Framework PHP“, de Ademir Cristiano Gabardo, cedido gentilmente pela editora Novatec, através de contato que tive com Mariana Prates, do departamento de marketing.

Dada a óbvia relação entre o livro e o assunto principal deste blog, CodeIgniter, fui convidado a ler a obra e escrever algumas palavras com minhas considerações sobre o melhor framework PHP!

Estruturação do livro CodeIgniter Framework PHP

O livro “CodeIgniter Framework PHP” é estruturado em 15 capítulos principais, quais sejam:

Para facilitar o entendimento dessas considerações, fica mais fácil agrupar determinados capítulos e discorrer com base nestes agrupamentos. Então, a fim de facilitar o entendimento, consideremos que o primeiro grupamento, a qual chamaremos “Início“, abrange os capítulos 1, 2, 3 e 4; o seguinte, chamado “Meio“, envolve os capítulos 5, 6, 7, 8, 9, 10 e 11; e, por “Fim“, os capítulos restantes, 12, 13, 14 e 15.

CodeIgniter Framework PHP: “Início”

O livro, em seus capítulos iniciais, como não poderia deixar de ser, apresenta uma base teórica necessária para o entendimento e uso do CodeIgtniter. As primeiras dezenas de páginas se encarregam de explicar conceitos primordiais como design pattern, MVC, o conceito de model, view e controller e outros.

Inclusive, algumas considerações sobre a atual versão do framework e o que se pode esperar da próxima – o que, pessoalmente, considerei uma abordagem precoce, dado que o leitor iniciante ainda desconhece termos abordados, como “scaffolding”, “helpers”, “drivers”. Talvez a intenção de Ademir Gabardo tenha sido, justamente, suscitar curiosidade no leitor. É uma possibilidade…

Achei especialmente interessante a explicação de como montar um ambiente de testes para CodeIgniter, explicando como baixar, instalar e configurar Apache, PHP e MySQL, separadamente. É fato que existem programas que, nas palavras do próprio autor, são “pacotes de softwares ‘pré-embalados’”, ou seja, permitem instalar os sistemas citados de forma bem mais simples (um deles, inclusive, sendo citado pelo autor); mas, a meu ver, é interessante ao estudante saber algo sobre o funcionamento de servidores e instalação de aplicações nestes, tal como foi abordado no livro.

Depois disso, a estrutura de diretórios do CodeIgniter é explicada, mostrando para que serve e os cuidados necessários que se deve ter com cada pasta do CI. A essa altura, alguns exemplos básicos de uso de controllers e views já são apresentados, mostrando a quem está lendo como o CodeIgniter alia poder e simplicidade de uso para a construção de sites e aplicativos.

Evoluindo com as explicações, mais considerações são feitas sobre o funcionamento interno e funcionalidades nativas do framework e acontece a apresentação dos helpers, seguida de exemplos de como usar alguns helpers importantes e comuns quando se está usando o CodeIgniter.

CodeIgniter Framework PHP: “Meio”

Ademir Cristiano Gabardo, o autor do livro “CodeIgniter Framework PHP”, utilizou uma abordagem que julgo bastante eficiente quando o assunto é passar conhecimento técnico desta natureza: apresentou o modo de fazer, exemplos, nuances e alguns macetes através do desenvolvimento de um aplicativo “do mundo real”. Sua proposta foi criar um catálogo de produtos com o CI e, no processo, habituar seu leitor às ações e peculiaridades encontradas no processo. Mais um ponto positivo!

E o importante é que, no livro, o desenvolvimento de uma boa parte de um “sistema de verdade” é mostrado, com explicações de se fazer páginas de categorias e de detalhes de produtos (com recursos completos de visualização e paginação), recursos de busca, formulário para contato e área administrativa protegida por senha, reforçando a abordagem de exemplo de “aplicativo do mundo real” apresentada.

As explicações sobre este catálogo de produtos abrangeram desde a criação do banco de dados apropriado – mostrando o Diagrama Entidade Relacionamento, ou DER (chamado, no livro de “Esquema do banco de dados”), inclusive com a disponibilização da SQL necessária –, passando pela configuração de BD do próprio CodeIgniter e mostrando o fabuloso recurso scaffolding (que, conforme podemos encontrar nas primeiras páginas da obra, deixará de funcionar a partir da próxima versão do CI), até chegar no uso da Active Record, classe essencial do Code Igniter para qualquer site/aplicação que utilize banco de dados.

E um dos principais pontos fortes da obra: apresentação e exemplos de uso da biblioteca nativa do CodeIgniter para carrinho de compras, recurso de versões recentes do framework para facilitar a manipulação de operações envolvendo este conceito!

CodeIgniter Framework PHP: “Fim”

Nos capítulos finais da publicação, outros recursos não abordados para a criação do catálogo de produtos são apresentados.

Certamente o autor não deixaria seus leitores na mão quanto à apresentação e exemplos de uso de funcionalidades tão importantes como customização de páginas de erros, criação dinâmica de tabelas, operações variadas relacionadas a manipulação de imagens, criação de backups dinâmicos, recursos especiais de string e texto e, de forma complementar, exposição de outras possibilidades oferecidas pela Active Record.

Como plus, Gabardo explica uma das maneiras possíveis de se fazer a integração CodeIgniter + AJAX, tão essencial à quase totalidade de sites/aplicativos modernos.

CodeIgniter Framework PHP: considerações finais

Com o desenvolvimento do catálogo de produtos que fez parte da proposta do “CodeIgniter Framework PHP“, é possível tomar contato e receber explicações de muitos recursos excepcionais do framework, como transição de dados entre camadas do padrão MVC, tratamento de informações, segurança, criação de formulários, paginação, upload e tratamento de imagens e outros tipos de arquivos, roteamento de URLs, sessões, trabalho com carrinho de compras e muitos outros.

O livro é destinado a pessoas que tiveram pouco ou nenhum contato com o CodeIgniter – ou seja, o público iniciante – e, acredito, por este motivo, o autor foi feliz na quase totalidade das páginas de sua publicação.

Se fosse pedido para a avaliação do livro se dar através de pontuação de 1 a 10, “8,5” seria minha resposta. Excetuando-se um equívoco de tradução ou conceito aqui e acolá, digo, com toda certeza, que a obra é indicada e recomendada a todos os iniciantes em CodeIgniter que queiram aprender/reforçar desde conceitos básicos a alguns mais além. Ficou um gostinho de “quero mais” para uma edição ampliada! ;-)

Parabéns ao autor Ademir Cristiano Gabardo e à editora Novatec pela publicação!

Algumas vezes, em projetos feitos com CodeIgniter, é preciso realizar operações relativamente corriqueiras mas, principalmente quando se está começando a mexer com o framework, ainda não se tem confiança nem a “malandragem” de alterar/criar determinadas personalizações.

Este artigo aborda 5 dicas básicas do CodeIgniter que poderão salvar sua pele:

Remover “index.php” do URL

Como remover o index.php do URI é algo já bastante discutido (inclusive no artigo sobre URLs no Codeigniter) e que pode ser feito através de jeitos diferentes; mas é interessante incluir esta dica, também, para que o artigo tenha várias boas dicas em um só lugar.

Retirar o “index.php” do endereço de seus sites ou softwares feitos com CodeIgniter é uma das primeiras coisas que devem ser feitas quando se está configurando uma instalação do CI para um novo projeto, e é realmente simples de se fazer! Aliás, seria bastante interessante se, em versões futuras do framework, já houvesse um arquivo .htaccess padrão juntamente com o framework. Realmente facilitaria bastante…

Então, para excluir o segmento “index.php” das URLs no CodeIgniter, é preciso fazer 2 coisas. A primeira delas é editar o arquivo /system/application/config/config.php, alterando o valor da diretiva index_page para vazio:

1

$config['index_page'] = '';

A segunda etapa é a criação de um arquivo “.htaccess” (com um pontinho na frente, mesmo) na raiz de sua instalação do CodeIgniter. Como mencionado, existem diversas configurações diferentes para se alcançar o mesmo objetivo; para facilitar as coisas, coloquemos no exemplo o que é recomendado no Guia do Usuário Oficial do CodeIgniter. Portanto, depois de ter criado seu arquivo .htaccess, escreva o seguinte nele:

1
2
3

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

E é só isso! A partir de agora, os URLs de seu site/sistema feitos com CodeIgniter não terão mais o segmento (chamado de “irritante” por alguns) “index.php”.

O diretório “application”

Muitos desenvolvedores preferem mover a pasta “application” para fora da pasta fora da pasta “system” – prática, inclusive, da qual sou adepto. É interessante a abordagem de fazer uma separação mais evidente do código da aplicação do core do framework, embora oferecendo oportunidades para continuar a reforçar a segurança.

Não há nada especial que seja preciso fazer; basta mover a pasta “application” para fora da pasta “system”.

Então, a “nova” estrutura de diretórios fica:

É possível, também, mudar o nome da pasta da aplicação para algo mais significativo. Geralmente, quem usa esta abordagem faz isso, em parte, por trabalhar simultaneamente em uma série de projetos e, dessa forma, isso ajuda a descobrir mais facilmente onde se está. Outra razão pela qual isso pode ser útil é quando se pretende executar várias aplicações usando somente uma instalação do CodeIgniter – este é um tema que pode ser abordado em artigos futuros.

Em primeiro lugar, é preciso renomear a pasta “application” para o nome que se queira. Então, é preciso alterar o arquivo “index.php” que se encontra na raiz da instalação do CI. Basta procurar a variável $application_folder e digitar o novo nome para a pasta do aplicativo.

1

$application_folder = "meuSistemaCI"; // nome fictício...

Para garantir, vale a pena navegar por seu software e fazer uma verificação rápida para conferir se tudo ainda está funcionando bem! :-P

Mover o diretório “system”

Esta é uma medida que pode ser tomara para aumentar a segurança de sua aplicação CodeIgniter. A ideia é mover a pasta “system” para um nível em que fique fora da área pública da instalação padrão, consequentemente, ficando “fora de perigo”.

É preciso conhecer a estrutura de diretórios de seu servidor para fazer a mudança e o apontamento correto para a nova localização. Como exemplo didático, tomemos o uso do WampServer para a instalação do CI. Nessas condições, a nova estrutura de pastas ficaria da seguinte maneira (nomes também ilustrativos):

Agora é necessário alterar a variável $system_folder do arquivo “index.php”, na raiz da instalação, para refletir essa mudança:

1

$system_folder = "../system";

Frisando: é preciso conhecer a estrutura de diretórios para fazer a correta referência à pasta “system”. Depois da mudança, faça uma verificação rápida para conferir se tudo ainda está funcionando como deveria.

Usar um diretório “views” alternativo

Apesar de não ser uma prática tão utilizada dentre os desenvolvedores CodeIginter (eu, pelo menos, não vejo sem feito com frequência), é possível usar um diretório alternativo para “views”. Quem usa esta técnica alega que a separação de código e interface fica mais fácil, já que o diretório das views não fica “afundado” em uma estrutura de muitos subdiretórios. Então, eles se valem disso para poder ter a pasta no diretório raiz.

Crie a pasta na raiz, como faria normalmente. Para o exemplo, a pasta pode ser “templates”, mas, claro, você dá o nome que quiser.

A fim de o CI reconhecer esse novo diretório como o padrão para as views, é preciso estender uma das bibliotecas do core do framework. O CodeIgniter é tão fantástico que, por padrão, permite estender facilmente suas funções nativas (o que facilita bastante o serviço e evita alterar o código fonte original).

Primeiro, é preciso criar uma nova biblioteca dentro da pasta “application” (ou talvez você tenha alterado o nome dela usando a dica anterior!), que precisa ser nomeada apropriadamente para que o CI a reconheça! Ele deve ser chamado “MY_Loader.php” e conter o seguinte:

1
2
3
4
5
6
7

Class MY_Loader extends CI_Loader {
    function MY_Loader()
    {
    	parent::CI_Loader();
    	$this->_ci_view_path = 'templates/';
    }
}

Atenção! Antes de continuar, lembre-se de mover todos as views existentes para o novo diretório! Do contrário, você será premiado com uma família inteira de erros!

Diretório para imagens, estilos, javascript e outros

Geralmente é bom ter diretórios próprios para imagens, folhas de estilo, javascript e demais recursos necessários para o desenvolvimento de sites/sistemas. Se for em um local unificado ao invés de espalhar os “assets” pela estrutura de diretórios do CodeIgniter, então, é melhor ainda!

Fazer isso é algo simples e existem diversas maneiras de se conseguir. Uma dessas maneiras (pesquise para encontrar mais, vale a pena) é ter um diretório “assets” na raiz da instalação com subdiretórios para cada tipo de recurso que se precise:

Então, para fazer as chamadas aos recursos, basta fazer como:

1
2
3
4
5
6
7
8

// Fazer link para um css (precisa do HTML Helper)
echo link_tag('assets/css/styles.css') . "\n";
 
// Especificar caminho de uma imagem
<img src="<?php echo base_url() . 'assets/img/image.jpg' ?>" alt="alt text" />
 
// Link para um javascript
<script type="text/javascript" src="<?php echo base_url() . 'assets/js/jquery.js' ?>"></script>

Mãos à obra!

Como falado diversas maneiras durante o artigo, existem muitos jeitos para se alcançar os mesmos resultados apresentados aqui. Estas dicas são excelentes, mas não são as únicas a serem realizadas. Certamente são boas dicas e, caso você tenha necessidade de aplicar alguma(s) técnica(s) mostrada, já sabe uma das maneiras de conseguir.

O jeito é experimentar e experimentar, procurar outras dicas similares e, com o tempo e experiência, criar suas próprias maneiras de facilitar o fluxo do CodeIgniter (que já é simples, diga-se de passagem) e aprimorar dicas de outras pessoas. Os conceitos de “comunidade” e “colaboração” tem a ver com isso, meus amigos!

E você, tem alguma boa dica de configuração do CodeIgniter para compartilhar?

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!