No artigo sobre como criar páginas estáticas no CodeIgniter houve uma dúvida: mas e se quiséssemos interagir com o banco de dados pra isso? Para sanar esta dúvida, portanto, vamos a um tutorial de como fazer um sistema de “news” usando o CodeIgniter!

Schema do sistema de news

Use o seguinte database schema para criar a tabela do exemplo deste artigo:

1
2
3
4
5
6
7
8

CREATE TABLE news (
    id int(11) NOT NULL AUTO_INCREMENT,
    title varchar(128) NOT NULL,
    slug varchar(128) NOT NULL,
    text text NOT NULL,
    PRIMARY KEY (id),
    KEY slug (slug)
);

A partir de agora, também é muito importante você ficar familiarizado com os métodos do Active Record (que, brevemente, terá seu nome trocado para Query Builder) Query Builder (antigo Active Record). Portanto, acesse a página do manual oficial que trata do Active Record e familiarize-se com os métodos de seleção, inserção, atualização e deleção de dados.

Por exemplo, vamos criar um método no model que permite pegar todas as news cadastradas ou pegar somente uma ao passar seu slug.

1
2
3
4
5
6
7
8
9
10
11

public function get_news($slug = FALSE)
{
    if ($slug === FALSE)
    {
        $query = $this->db->get('news');
        return $query->result_array();
    }
 
    $query = $this->db->get_where('news', array('slug' => $slug));
    return $query->row_array();
}

Configurando o model

Vamos configurar o model para nosso sistema de news. Ele será armazenado em application/models/news_model.php e será algo como:

1
2
3
4
5
6
7
8
9

<?php
class News_model extends CI_Model {
 
    public function __construct()
    {
        $this->load->database();
    }
 
}

Este código é semelhante ao código do controller usado no artigo sobre páginas estáticas. Ele cria um novo model que extende o CI_Model e carrega a library de banco de dados. Isso fará com que a classe de banco de dados esteja disponível através do objeto $this->db.

Mostrando as news

Agora que as consultas podem ser feitas, vamos partir para a exibição das news, fazendo a integração MVC. Crie o controller application/controllers/news.php, que terá o seguinte código:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35

<?php
class News extends CI_Controller {
 
    public function __construct()
    {
        parent::__construct();
        $this->load->model('news_model');
    }
 
    public function index()
    {
        $data['news'] = $this->news_model->get_news();
        $data['title'] = 'News archive';
 
        $this->load->view('templates/header', $data);
        $this->load->view('news/index', $data);
        $this->load->view('templates/footer');
    }
 
    public function view($slug)
    {
        $data['news'] = $this->news_model->get_news($slug);
        if (empty($data['news_item']))
        {
            show_404();
        }
 
        $data['title'] = $data['news_item']['title'];
 
        $this->load->view('templates/header', $data);
        $this->load->view('news/view', $data);
        $this->load->view('templates/footer');
    }
 
}

E, agora, o arquivo de view que mostra todos os artigos, application/views/news/index.php, que terá o seguinte código:

1
2
3
4
5
6
7
8
9
10
11

<?php foreach ($news as $news_item): ?>
 
    <h2><?php echo $news_item['title'] ?></h2>
 
    <div id="main">
        <?php echo $news_item['text'] ?>
    </div>
 
    <p><a href="news/<?php echo $news_item['slug'] ?>">Ver artigo</a></p>
 
<?php endforeach ?>

Por fim, o view que mostra a página de cada artigo, application/views/news/view.php:

1
2
3

<?php
echo '<h2>' . $news_item['title'] . '</h2>';
echo $news_item['text'];

Roteamento

Uma revisada no artigo sobre routes no CodeIgniter vai permitir uma configuração de rotas para facilitar o acesso aos artigos e aprimorar nosso sistema:

1
2
3
4

$route['news/(:any)'] = 'news/view/$1';
$route['news'] = 'news';
$route['(:any)'] = 'pages/view/$1';
$route['default_controller'] = 'pages/view';

E, com isso, está pronto nosso sistema de news no CodeIgniter! Popule o banco com alguns registros e acesse http://localhost/news (depois de já ter removido o segmento “index.php”) para o ver em funcionamento.

Conclusão

Alguns estiveram impacientes por tutoriais mais práticos, como este, mas, até agora, os artigos da seção Passos Iniciais eram de suma importância.

Se você vem acompanhando o CodeIgniter Brasil, ao ver este tutorial completo, certamente não deve ter sentido dificuldade em acompanhar os conceitos e técnicas apresentados.

Valeu ou não a pena? ;-)

Quando se está preparando o ambiente de desenvolvimento para CodeIgniter, é importante levar em consideração uma questão primordial: segurança. Durante o desenvolvimento de um site ou sistema, existem muitas ações/verificações possíveis de se fazer a fim de aumentar a segurança da aplicação. Felizmente, o CI já vem, por padrão, com uma série de opções e configurações que ajudam bastante, neste sentido, através de sua classe de segurança, a Security Class.

Configurações de segurança padrão

Segurança de URI

O CodeIgniter é bastante restritivo em relação aos caracteres permitidos em URIs. Isso é para minimizar a possibilidade de que dados maliciosos possam ser passados ​​para a aplicação. Por padrão, URIs podem conter apenas os seguintes caracteres:

• Texto alfanumérico
• Til: ~
• Porcento: %
• Ponto: .
• Dois pontos: :
• Underscore: _
• Traço/Menos: -

Apesar de ser desaconselhado, é possível especificar mais caracteres – ou suprimir algum(ns) desse(s) – no arquivo de configuração, /application/config/config.php.

Register_globals e magic_quotes_runtime

Durante a inicialização do sistema, todas as variáveis ​​globais não estão setadas, exceto as encontradas em $_GET, $_POST e $_COOKIE. A rotina de desativação é a mesma usada na diretiva “register_globals = off”.

A diretiva “magic_quotes_runtime” está desligada durante a inicialização do framework para que não seja preciso remover barras quando em consultas em bancos de dados.

Isso o CodeIgniter já faz por padrão, então, não precisa se preocupar com nada, somente fique sabendo. :-)

error_reporting

Em ambientes de produção, normalmente é desejável desativar o reporte de erros do PHP, definindo o sinalizador “error_reporting” para “0″. Isso desativa erros nativos do PHP que está sendo processado, que pode, potencialmente, conter informações confidenciais. Mas, em ambientes de desenvolvimento e testes, é importante que esses erros apareçam.

Mais sobre os diferentes ambientes e como gerenciar configurações e variáveis facilmente, leia o artigo que explica como trabalhar com diversos ambientes no CodeIgniter.

Melhores práticas de segurança para CodeIgniter

Como “regras gerais”, existem algumas práticas que podem ser levadas em consideração no momento de desenvolver aplicações com CodeIgniter. Na verdade, são regras de segurança até mesmo para quando não se está usando o CI!

Antes de aceitar qualquer dado em sua aplicação, sejam dados POST vindos de formulários, COOKIES, dados de URIs, dados XML-RPC ou, até, informações de SERVER, é possível tomar 3 precauções em nome da segurança:

1. Filtrar dados.
2. Validar os dados para assegurar sua conformidade com o tipo correto, comprimento, tamanho, etc (algumas vezes, isso pode substituir o item anterior)
3. Tratar dados antes de submetê-los ao banco de dados

Para ajudar nessa trinca de segurança, o próprio CodeIgniter já vem com alguns recursos para ajudar.

Filtro XSS

Cross-site scripting (ou XSS) é um tipo de ataque perigoso, mas, felizmente, o CodeIgniter já apresenta meios de proteger a aplicação através de uma de sua Security Class.

Validação de dados

CodeIgniter tem uma Classe de validação de formulário que serve para validar, filtrar e preparar dados.

Escapar dados antes de terem contato com o Banco de Dados

Nunca insira informação em seu banco de dados sem escape! Existe uma seção específica para isso no manual oficial do CI.

Conclusão sobre Segurança no CodeIgniter

Não somente quando se usa CI, mas em todo projeto web, levar a segurança em consideração é um dos passos mais importantes para garantir que seu site ou aplicação tenha qualidade.

Este artigo mostrou somente em linhas gerais como o CodeIgniter, em seu status de melhor framework PHP, já tem, por default, diversos recursos e abordagens para tratar essa questão de segurança.

Serão lançados, aqui no blog, artigos específicos sobre cada um dos pontos citados. Assine o feed para não perder a leitura e garantir que a segurança de seus aplicativos em CodeIgniter esteja em dia!

Recentemente chegou uma dúvida interessante: como criar “páginas estáticas” com o CodeIgniter? Por “páginas estáticas” quem perguntou quis dizer aquele tipo de página mais “institucional”, em que o conteúdo não se altera muito, tal como uma página Sobre, Termos de Uso, Política de Privacidade, etc.

Essa dúvida é tão comum para quem está começando no mundo CI que o manual oficial tem até um tutorial explicando! Mas, para não dizer que por aqui não tem colher de chá, vamos explicar detalhadamente como é o processo de fazer páginas estáticas usando CodeIgniter.

O raciocínio

A lógica por trás da criação de páginas estáticas com CI é bastante simples: para gerenciar essas páginas, um controller simples, que não vai fazer muita coisa além de servir corretamente os respectivos views.

Além disso, algumas configurações de rotas para direcionar a requisição à página correta.

Então, basicamente o que é preciso saber/mexer:

• Controller
• Configuração de rotas

Felizmente, tudo já explicado, aqui, no CodeIgniter Brasil! ;-)

O controller

Seguindo nosso complexo plano de ação, vamos criar um controller. É bastante lógico que ele se chame “paginas”, “pages” ou qualquer coisa neste sentido. Vamos no “pages” para manter a característica estadunidense do CI. :-P

Portanto, crie o arquivo application/controllers/pages.php com o seguinte conteúdo:

class Pages extends CI_Controller {
 
    public function view($page == 'home')
    {
 
    }
 
}

Ou seja, o controller “pages” terá uma função view() para gerenciar as requisições a páginas estáticas; função esta que exibirá, por padrão, a página estática “home”. Como sabemos das facilidades dos controllers e sua relação com os URLs do site, o acesso às páginas será bem simplificado:

http://localhost/pages/sobre
http://localhost/pages/termos-de-uso
http://localhost/pages/politica-de-privacidade

Isso levando em conta que já se está suprimindo o “index.php” do URL, tal como mostrado no artigo sobre URLs no CodeIgniter.

Mas onde vai estar o conteúdo dessas páginas, já que não estamos tratando com bancos de dados? Há uma maneira bastante simples de se fazer: um arquivo para cada página! Com isso, para se alterar o conteúdo de uma página, basta alterar o conteúdo de seu respectivo arquivo.

Deixemos no ar a ideia de colocarmos estes arquivos em application/views/pages/.

Templates para exibição

Para exibir estes conteúdo, são precisas views. Como vimos no artigo sobre views no CodeIgniter, é possível “combinar” diversas views, carregando-as em sequência.

Parece uma boa ideia fazer um topo e um rodapé, neste caso. Dessa forma, quando for preciso alterar alguma coisa, uma só atualização afetará todas as páginas do site. Criemos, então, 2 arquivos.

application/views/templates/header.php

<html>
<head>
	<title><?php echo $title ?> - Meu Site em CodeIgniter</title>
</head>
<body>
	<h1><?php echo $title ?></h1>

application/views/templates/footer.php

<strong>&copy; <?php echo date('Y') ?></strong>	
</body>
</html>

Adicionando lógica ao controller

Para o exemplo, vamos criar no diretório de “pages” – application/views/pages/ – os arquivos “sobre.php” e “contato.php”. Então, é hora de fazer a mágica acontecer em nosso controller:

public function view($page = 'home')
{
    // Se o arquivo correspondente não existir no diretório, erro
    if ( ! file_exists('application/views/pages/' . $page . '.php'))
    {
        show_404();
    }
 
    // Título da página é o próprio nome com a primeira letra em maiúsculo
    $data['title'] = ucfirst($page);
 
    // "Monta" a apresentação usando as views
    $this->load->view('templates/header', $data);
    $this->load->view('pages/' . $page, $data);
    $this->load->view('templates/footer', $data);
}

Lembra de como passamos dados para as views, não é? Qualquer coisa, dê uma recapitulada no artigo sobre views.

Configurando as rotas

Por fim, vamos configurar as rotas da forma apropriada a permitir que o acesso a essas páginas estáticas seja feito através de URLs mais simples. Para isso, conforme foi visto no artigo sobre rotas no CodeIgniter, abra o arquivo application/config/routes.php e adicione o seguinte:

$route['default_controller'] = 'pages/view';
$route['(:any)'] = 'pages/view/$1';

Com essa configuração de rotas, o que fizemos foi instruir o CodeIgniter a:

• O controller padrão é o pages/view
• Quando qualquer requisição for feita, esta será usada como parâmetro da função view() do controller pages

E, a partir de agora, basta acessar as páginas de seu site e ser feliz:

http://localhost/sobre
http://localhost/contato

Conclusão

Como pudemos ver, criar página estáticas com CodeIgniter não tem mistério: basta alguns arquivos num diretório, criar um controller para gerenciar tudo e simplificar o acesso usando regras simples de rotas.

E, se você também tem uma dúvida sobre o CodeIgniter, basta enviar um tweet para @codeigniterbr que tentaremos fazer um artigo em até 2 anos úteis! ;-)

O CodeIgniter é o melhor framework PHP da atualidade e, para corroborar esta informação, veremos que é possível trabalhar com diversos “ambientes” no CI. Mas o que, exatamente, isso significa?

O que são “ambientes” no CodeIgniter?

Em desenvolvimento de software – principalmente quando se trabalha com algum tipo de controle de versões – é bastante comum existirem diversos “ambientes“. Quando se desenvolve software (e sistemas e aplicações web estão aí inclusos), é desejável que determinadas configurações de seu ambiente de desenvolvimento sejam diferentes, dependendo de onde estão atualmente sendo executadas.

Por exemplo, quando se está programando, é desejável que a exibição de erros esteja habilitada. Afinal, este tipo de informação é útil para o(s) programador(es) e, como o site ainda não está “aberto ao público”, não há perigo em expor quaisquer configurações e/ou paths referentes ao projeto. Já para quando o site está “aberto”, é importante que este tipo de informação não seja exibida, já que exibe informações críticas relativas ao software e atrapalha a experiência do visitante/usuário – imagine erros de MySQL sendo exibidos para um pobre visitante que veio de uma SERP…

Geralmente existem 3 ambientes:

• desenvolvimento. Como sugere o próprio nome, é o ambiente usado pelos desenvolvedores para a produção e aprimoramento do software.
• homologação ou teste. Quando chegar o momento de testar o software (isso varia conforme o projeto, metodologia, equipe, etc), é neste ambiente em que isso é feito. O ambiente, além de estar disponível para “testadores oficiais” que fazem parte da equipe, também pode ser acessado por usuários escolhidos ou outras pessoas.
• produção. Acessado pelos visitantes e “usuários finais”. É quando já de desenvolveu/aprimorou o projeto (ou alguma parte específica dele), isso já foi passado (e aprovador) no ambiente de testes e, agora, está disponível para todas as pessoas.

Essas não são nomenclaturas “oficiais” e nem os ambientes precisam se restringir a 3, mas esse é o dia-a-dia da maioria dos projetos de desenvolvimento de software e funciona muito bem, obrigado! ;-)

E, como não poderia deixar de ser, uma das características do CodeIgniter é permitir que se lide com esses diferentes ambientes e suas respectivas configurações de forma bem fácil e simples!

Como configurar ambientes no CodeIgniter

A configuração de ambientes no CodeIgniter se dá, principalmente, no arquivo index.php. Nele, logo no início, há a definição da constante ENVIRONMENT. É aqui que se define qual ambiente será usado para a execução do CI.

Logo abaixo tem um switch. Ele simplesmente checa qual é o tipo de ambiente e, dependendo do resultado, aplica diferentes configurações.

E pode parecer incrível, mas é somente isso! Somente definindo qual ambiente será usado no momento (e que vai ser configurado segundo as configurações/diretrizes definidos no switch), já temos um controle de ambientes no CodeIgniter!

Exemplo de configuração de ambientes

Como se trata de um switch simples, é possível definir qualquer coisa que se queira para os diferentes ambientes. Voltemos ao exemplo da exibição de erros segundo o ambiente. Aproveitando, vamos suprimir o salvamento de queries ao BD quando não for necessário. Veja como é simples configurar o switch:

switch (ENVIRONMENT)
{
    case 'desenvolvimento':
        error_reporting(E_ALL);
	break;
 
    case 'teste':
    case 'producao':
	error_reporting(0);
        $this->db->save_queries = FALSE;
	break;
 
	default:
	exit('O ambiente da aplicação não está definido corretamente.');
}

Então, se o ambiente estiver configurado como “desenvolvimento”, os erros serão exibidos e as queries salvas.

define('ENVIRONMENT', 'desenvolvimento');

Caso esteja definido o ambiente de “teste” ou “producao”, os erros e salvamento de queries são suprimidos.

define('ENVIRONMENT', 'teste');

Ou seja, mudando 1 palavra em 1 linha de código é possível alternar entre os diferentes ambientes (lembrando que não precisando ser somente 3, seu switch pode ter quantos você quiser) e colher os benefícios de suas respectivas configurações.

Fluxo do software controlado pelo ambiente atual

Além de definir configurações que variam conforme o ambiente em que se esteja, também é possível definir o fluxo da aplicação e/ou executar funções específicas. Trata-se, tão somente, de uma constante que é definida, portanto, nada impede que, em algum controller, tenha-se um condicional do tipo:

if (ENVIRONMENT == 'desenvolvimento')
{
    // Código somente para o ambiente de desenvolvimento
}

Conclusão

Como vimos, lidar com diferentes ambientes em desenvolvimento de software usando CodeIgniter é tão difícil quanto alterar 1 linha de código… Configurando corretamente cada ambiente, é possível garantir maior segurança, desempenho e estabilidade ao projeto, já que é possível estabelecer diretivas específicas para cada um.

E você, tem alguma dica ou configuração que gostaria de recomendar para cada ambiente? Comente!

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.