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

Um pouco de história

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

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

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

Helper

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

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

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

Library

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

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

Plugin

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

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

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

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

Em artigos futuros serão abordados helpers, libraries e plugins com mais detalhes (assine o feed do CodeIgniter Brasil para não perder), mas, certamente, é programando e testando bastante que você vai conhecer as melhores práticas e “manhas” do CodeIgniter.

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

Controllers no CodeIgniter

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

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

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

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

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

Estrutura de um Controller no CodeIgniter

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

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

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

O nome da classe deve iniciar com letra maiúscula

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

class Noticias extends Controller
{
}

Isso é errado:

class noticias extends Controller
{
}

Deve haver um construtor

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

1
2
3
4
5
6
7

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

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

O arquivo deve ter o mesmo nome da classe

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

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

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

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

Funções em um Controller no CodeIgniter

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

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

1
2
3
4
5
6
7

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

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

Funções privadas em controllers

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

function _funcaoqualquer()
{
  // códigos
}

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

Definindo um Controller padrão

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

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

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

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

E isso é tudo sobre controllers no CodeIgniter?

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

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

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

Estrutura de URL no CodeIgniter

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

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

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

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

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

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

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

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

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

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

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

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

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

Removendo o segmento “index.php”

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

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

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

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

Adicionando sufixo ao URL

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

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

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

Trabalhando com Query Strings

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

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

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

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

index.php?c=estatisticas&m=mostrar

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

Conclusão sobre URLs no CodeIgniter

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

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

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

Estrutura de diretórios do CodeIgniter

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

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

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

Visão geral da estrutura de pastas do CodeIgniter

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

Diretórios

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

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

Arquivos

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

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

system

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

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

system/application

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

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

1
2
3

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

O importante é a função de cada pasta

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

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

Baixando o CodeIgniter

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

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

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

Instalação  do CodeIgniter

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

Para instalar o CodeIgniter, basta seguir os seguintes passos:

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

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

Atualizando o CodeIgniter

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

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

Dica de segurança

Se você desejar aumentar a segurança de sua instalação, é possível “camuflar” a localização dos arquivos de seu CI renomeando a pasta system para algo de sua preferência. Se optar por isso – o que, geralmente, é uma boa pedida de segurança – você deve abrir o arquivo index.php (localizado na raiz do CodeIgniter) e alterar a variável $system_folder com o nome que você escolheu.

Ainda comentaremos bastante sobre a estrutura do CodeIgniter, configurações, diretivas e várias outras coisas. Por enquanto, é isso, mas fique ligado no CodeIgniter Brasil para acompanhar as novidades!

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

Bem, esse é o fluxograma:

Fluxograma de Dados do CodeIgniter (clique para ampliar)

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

“Seguindo as setinhas”

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

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

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

Bem tranquilo… Por enquanto!  ;-)

Bem, chegou a hora de começar a abordar os assuntos referentes ao CodeIgniter, propriamente dito, já que a “base teórica” já foi dada e vocês, queridos leitores, certamente já procuraram estudar e buscar mais informações sobre tudo o que foi dito até agora, não é?

Requisitos de Servidor para rodar o CodeIgniter

Como já estamos falando há algum tempo, o CodeIgniter consegue alinhar boa performance, poderosos recursos, simplicidade e leveza, ao mesmo tempo! Para se ter ideia, o arquivo compactado do framework tem menos de 900KB e, quando está em uso, seus arquivos ocupam menos de 3MB no servidor (na versão mais atual na data de publicação deste artigo).

CodeIgniter é um framework PHP e, como era de se esperar, sua “instalação” consiste em descompactar seus arquivos no servidor, alterar pouquíssimas linhas de código para configurações preliminares e começar a usar! Para rodar o CodeIgniter, o servidor precisa de:

• PHP 4.3.2 ou superior. Sim, CodeIgniter é escrito para ser compatível com PHP4! Os próprios desenvolvedores afirmam que teria sido muito mais fácil escrever o framework utilizando os recursos do PHP5; entretanto, eles optaram por escrever em PHP4 para, dentre outros motivos, não “alienar” público em potencial de programadores. Mas, calma! O CodeIgniter irá ser rescrito totalmente em PHP 5 – quando a equipe julgar conveniente.
• Banco de Dados. Na verdade ter um banco de dados não é obrigatório, mas se for para desenvolver algo que não use banco de dados, então nem precisa usar CodeIgniter… Atualmente há suporte para MySQL (4.1+), MySQLi, MS SQL, PostgreSQL, Oracle, SQLite e  ODBC. E, como veremos em artigos futuros, alternar o uso entre estes é facinho, facinho!  ;-)

Licença de Uso

Como qualquer software, o Code Igniter possui uma licença de uso. Licença esta que é um acordo legal entre quem usa o CodeIgniter e a EllisLab Inc, empresa mantenedora do framework. É permitido usar, copiar, modificar e distribuir o CodeIgniter e sua documentação, com ou sem modificações, para qualquer finalidade, desde que sejam cumpridas as seguintes condições:

1. Uma cópia da licença deve ser incluída com a distribuição;
2. As redistribuições do código fonte devem reter a observação de copyright em todos seus arquivos;
3. As redistribuições na forma binária devem reproduzir a observação de copyright na documentação e/ou outros materiais fornecidos com a distribuição;
4. Os arquivos que foram modificados devem conter avisos indicando a natureza da alteração e os nomes de quem os alterou;
5. Produtos derivados devem incluir um aviso de que eles são derivados de CodeIgniter na sua documentação e/ou outros materiais fornecidos com a distribuição;
6. Produtos derivados não pode ser chamado de “CodeIgniter”, nem pode “CodeIgniter” aparecem em seu nome, sem autorização prévia por escrito da EllisLab Inc.

Essas são as condições no momento da publicação deste artigo, pode ser que haja alterações. Outras 3 coisas importantíssimas são:

1. Indenização. Ao usar o CodeIgniter, Você concorda em indenizar e defender os autores do software e eventuais contribuições para quaisquer efeitos diretos, indiretos, incidentais ou consequentes reclamações de terceiros, ações ou fatos, bem como de quaisquer despesas, responsabilidades, danos, acordos ou honorários decorrentes de seu uso ou mau uso do software ou uma violação de quaisquer termos da licença.
2. Isenção de Garantia. O software é fornecido “como está”, sem qualquer tipo de garantia, expressa ou implícita, incluindo, mas não se limitando a garantias de qualidade, desempenho, não violação, comerciabilidade ou adequação a uma finalidade específica.
3. Limitações de responsabilidade. Você assume todos os riscos associados com a instalação e utilização do software. Em nenhum caso o autor ou direitos de autor do software pode ser responsabilizado por reclamações ou outros danos decorrentes da responsabilidade civil, a partir de ou em conexão com o software. Titulares de licença são os únicos responsáveis por determinar a adequação do uso e assumir todos os riscos associados à sua utilização,incluindo mas não limitados aos riscos do programa, erros, danos aos equipamentos, perda de dados ou programas ou indisponibilidade ou interrupção de operações.

Quer dizer, é possível usar amplamente o CodeIgniter, mas você assume toda a responsabilidade em usá-lo! Quando fizer softwares utilizando o framework (inclusive os de distribuição em modo binário), você deve liberar juntamente o aviso de copyright (em todos os arquivos) e avisar que é um produto derivado (apesar de você não poder incluir o nome “CodeIgniter” no produto).

Vai encarar?  :-D

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

10. Arquitetura MVC

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

9. Quase nenhum pré-requisito para o servidor

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

8. Fácil de entender e extender

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

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

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

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

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

5. Ferramentas de segurança pré-prontas

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

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

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

3. Comunidade grande e ativa

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

2. Documentação excelente

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

1. Logo mais irá se unificar com o ExpressionEngine

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

O MVC (Model – View – Controller) já foi citado no artigo sobre padrões de projeto e no artigo introdutório sobre CodeIgniter; foi citado que o MVC é um dos padrões que o CodeIgniter implementa em seu core. Também foi dito que não é preciso saber tanto sobre o que ou como o CodeIgniter implementa os padrões de projeto. Bem, esta é a regra geral. O MVC é uma exceção a isso! É muito importante saber o que é e como funciona o padrão MVC no CodeIgniter a fim de saber como tirar o melhor proveito do framework!

Na verdade, saber sobre o conceito e como funciona o MVC é imprescindível para que você possa mexer, o mínimo que seja, com o CodeIgniter, já que todo o funcionando do framework se dá a partir da lógica e estrutura do MVC.

Por que “MVC”?

Atualmente muitos – muitos, mesmo – softwares utilizam o padrão MVC como base de funcionamento e, no caso, não é à toa, pois a abordagem é realmente muito boa e a lógica por trás faz “valer a pena” adotar o MVC.

O MVC pode ser entendido como uma divisão de tarefas em um aplicativo. Cada um dos 3 – Model, View e Controller – tem sua função bem definida (na teoria) e executa exatamente o que deve; nada além, nada aquém.

Com o desenvolvimento e evolução dos programas e, consequentemente, da forma de se fazer os programas, novas abordagens tiveram que ser pensadas para facilitar a programação e garantir que os softwares, depois de prontos, fossem mais facilmente manuteníveis. A partir disso surgiu o conceito de dividir tarefas, de garantir com que cada “camada” da aplicação tenha seu próprio escopo e definição e que a comunicação entre todas elas se dê de maneira eficiente e controlada.

Façamos uma analogia interessante envolvendo o HTML e o advento do CSS. “Antigamente”, a parte “estética” dos sites era controlada diretamente via tags HTML; se se queria um título na cor vermelho, colocava-se a tag para cores em vermelho; se se quisesse a fonte de tamanho “x”, colocava-se a tag para o texto ficar deste tamanho; e assim por diante. O problema era quando havia um site com 20 páginas ou mais e era preciso alterar o tamanho e a cor de todos os títulos…

Pensando nisso, Håkon Wium Lie teve a brilhante ideia de criar as folhas de estilo em cascata, tão conhecidas hoje em dia como “CSS”. Com CSS, a “aparência” do site, apesar de ser intrinsecamente relacionada com seu conteúdo, pode (e deve) ser controlada de forma independente, em arquivos separados, de forma a garantir a manutenção de um sem intervir no campo de atuação do outro.

E, mais ou menos da mesma maneira, se dá com o padrão MVC: existem funções/objetivos/escopos diferentes para o Model, para o View e para o Controller e cada um destes pode ser alterado, separadamente, por pessoas diferentes, sem interferir/intervir na “área de atuação” do outro! É algo fantástico!

Entendendo o Model, o View e o Controller

Na maioria das fontes que você pesquisar sobre MVC, geralmente vai encontrar primeiramente a explicação de “View” – provavelmente por ser a mais fácil de entender e/ou para não “assustar” muito no primeiro contato com o padrão de projeto. Mas, para seguir corretamente o acrônimo, serão apresentados, respectivamente, o Model (“Modelo”), o View (“Visualização”) e o Controller (“Controle”).

• Model. Tenha uma coisa em mente: quando pensar em Model, pense em estruturas de dados! Num software baseado em MVC, é o Model que tem o contato com as informações armazenadas e que são mostradas, estejam elas em um banco de dados, arquivo XML, ou onde quer que estejam. É no Model e somente no Model que as operações de CRUD devem acontecer.
• View. É a apresentação, é o que aparece, é o que é visualizado por quem usa o sistema. É no View que as informações, sejam elas quais forem e de de qual lugar tenha vindo, serão exibidas para a pessoa – logicamente acompanhadas de um bom design, uma boa estrutura organizacional, um ambiente agradável para quem está vendo, e muitos outros.
  
• Controller. Como sugere o nome, é responsável por controlar todo o fluxo do programa. É o “cérebro” e o “coração” do aplicativo; é no Controller que se decide “se”, “o que”, “quando”, “onde” e tudo o mais que faz com que a lógica funcione. Desde o que deve ser consultado no banco de dados à tela que vai ser exibida para quem usa o programa/sistema, é no Controller que tudo isso deve ser definido.

Certamente com estas breves descrições não é possível ter um entendimento satisfatório sobre o MVC. Então, leia a definição de MVC da Wikipédia, uma explicação sobre MVC de José Carlos Macoratti e uma explicação de MVC de Maikon Portela. Com essas leituras você certamente vai entender melhor sobre a o padrão MVC. Para facilitar ainda mais, veja esta representação esquemática do modelo MVC (com o perdão da “tradução mais ou menos” que fiz a partir da imagem do Streek):

Como dito, o CodeIgniter utiliza fortemente o padrão MVC para seu funcionamento e o MVC é parte importantíssima de seu “fluxo” de funcionamento; e existem muitos outros, como Bibliotecas (libraries), “Ajudantes” (helpers), Extensões (plugins) e outros. Mas isso é assunto para outro artigo!  ;-)

Fiquem ligados no CodeIgniter Brasil!

Quem já programa com linguagens OO (orientação a objetos) certamente trabalha ou, pelo menos, já ouviu falar, dos Padrões de Projeto ou Design Patterns. Os mais “vivenciados” na arte de programar já devem, inclusive, ter implementado um Padrão de Projeto em algum sistema ou software.

Mas nem todos conhecem os Padrões de Projeto e alguns sequer ouviram falar a respeito; por isso, neste artigo, falo um pouco a respeito dos Design Patterns. Para entender melhor o assunto, é preciso ter, pelo menos, noções de programação orientada a objetos – dê uma lidinha em nossa página Pré-requisitos para saber se você está apto a continuar a leitura.

O que são Padrões de projeto ou Design Patterns?

Primeiramente, vamos ler um trecho da definição de Padrões de Projeto da Wikipédia, onde consta que os Padrões de Projeto

descrevem soluções para problemas recorrentes no desenvolvimento de sistemas de software orientados a objetos. Um padrão de projeto estabelece um nome e define o problema, a solução, quando aplicar esta solução e suas conseqüências.

Excelente esta definição da Wikipédia. Para entender melhor, ainda, vamos pegar a definição mais objetiva de José Carlos Macoratti, que, em seu site, no artigo sobre o padrão MVC, define:

Padrões de projetos são soluções para problemas que alguém um dia teve e resolveu aplicando um modelo que foi documentado e que você pode adaptar integralmente ou de acordo com necessidade de sua solução.

Por exemplo, você está programando seu revolucionário sistema e percebe que será necessário ter acesso à uma instância de uma classe qualquer, e que esse acesso deve ser fácil e possível de ser feito em qualquer parte/página de seus códigos. Ao invés de você quebrar a cabeça e pensar em como fazer isso, utilize uma solução pronta! A solução para isso já existe – porque é uma situação muito comum em desenvolvimento de programas e se tornou um padrão de projeto – e seu nome é Singleton!

Quer dizer, corroborando ainda mais com a filosofia do “Não reinvente a roda!” – já comentada no artigo sobre frameworks -, os Padrões de Projeto existem para agilizar o desenvolvimento de aplicações e permitem que você “economize neurônios”, pois são soluções mais ou menos prontas para os problemas mais ou menos comuns do cotidiano de um programador.

E não se engane, pensado que padrões de projetos são “coisa de PHP”! Os design patters são soluções para problemas de software e, pense bem, uma solução para problemas genéricos não pode ficar restrita a uma linguagem específica. Portanto, conhecendo a solução que se quer, esta pode e deve ser aplicada não somente em PHP, mas em Java, Ruby, C#, .NET, e qualquer outra que você queira.

Para que servem os Padrões de Projeto?

Você já deve ter percebido que os Design Patterns servem para mostrar (ou demonstrar) soluções prontas para problemas que são comuns; soluções estas que podem ser implementadas em qualquer linguagem de programação.

O importante dos Padrões de Projeto são as definições dos problemas e a “melhor saída” para cada um deles. Através da análise de caso e de solução de uma situação, conhecendo os padrões de projeto você pode decidir qual usar, como usar e porque usar um padrão de projeto – se realmente for conveniente para o caso em foco.

Os padrões de projeto podem ser divididos por sua função ou escopo, sendo apresentados em 3 categorias principais, quais sejam, Padrões de Criação, Padrões Estruturais e Padrões comportamentais. Cada uma destas “categorias de padrões de projeto” contém os design patterns que são úteis a cada escopo.

Por exemplo, o padrão Singleton – que tem por objetivo garantir a existência de apenas uma instância de uma classe, mantendo um ponto global de acesso ao seu objeto – pertence à categoria de Padrões de Criação; o Adapter – que permite que classes com interfaces incompatíveis possam interagir entre si – pertence a Padrões Estruturais; e assim por diante. Confira uma boa listagem de padrões de projeto por categoria na Wikipédia.

Dando uma olhadinha no código fonte e pesquisando rapidamente em alguns tópicos dos fóruns oficiais do CodeIgniter, é possível observar que, dentre outros, alguns dos design patterns que o CodeIgniter implementa são:

• MVC
• Singleton
• Factory
• Adapter
• Decorator
• Strategy

Se alguém identificou mais algum padrão de projeto, basta comentar no artigo e eu complemento a listagem dos design patterns que o CodeIgniter implementa.

Na prática – e falando genericamente – não faz muita diferença para quem utiliza o CodeIgniter saber quais design patterns o framework usa nem exatamente como cada um deles funciona. Entretanto, saber disso auxilia você a “montar a tela mental” do “todo” e ter uma noção de como a “mágica” do CodeIgniter funciona!

Assine o feed CodeIgniter Brasil para não perder os próximos “truques”!  ;-)

Para quem programa/trabalha com PHP – e outras linguagens de programação, também -, sabe que o tempo de desenvolvimento é uma das coisas importantes a se considerar em um projeto. De igual maneira, deve-se fazer web sites e aplicações web que sejam confiáveis e seguros, ao mesmo tempo que possuam boa performance e sejam rápidos.

É possível conseguir estes objetivos programando “na unha” – jargão conhecido entre os programadores”; entretanto, isso possui algumas desvantagens como, só para citar algumas:

• Tempo “gasto” devido à preocupação com validações e segurança, em geral;
• Preocupações com o “estilo” da codificação, haja vista o fato de eventuais compatibilidades entre servidores e versões do PHP;
• Documentação;
• Escalabilidade;
• Combinar, de forma eficiente, leveza da aplicação e performance.

Para sanar, ou, pelo menos, amenizar, a maioria das questões apresentadas e outras mais, muitos programadores optam por utilizam um framework. Digo “um” porque, apesar da existência de inúmeros frameworks PHP, gratuitos ou não, o mais comum é o programador fazer alguns testes e escolher um só para trabalhar; escolher aquele que é mais consonante com sua metodologia e prática de programação – no caso, programação PHP.

Como você deve ter percebido pelo nome deste blog, aqui tratamos sobre o melhor framework PHP gratuito: CodeIgniter.

Sobre o CodeIgniter

CodeIgniter foi originalmente desenvolvido por Rick Ellis (CEO da EllisLab Inc.). O framework foi escrito para ter desempenho no “mundo real”, com muitos da classe bibliotecas, helpers e sub-sistemas baseados no código base do ExpressionEngine; atualmente é desenvolvido e mantido pela ExpressionEngine Development Team.

CodeIgniter, como bom framework que é, permite o desenvolvimento de web sites, softwares e aplicações em PHP de maneira ágil e relativamente descomplicada. O objetivo do CodeIgniter é disponibilizar um framework de máxima performance e capacidade, que seja flexível e o mais leve possível. Para conseguir estes objetivos, as bases do CodeIgniter são:

• Instanciamento dinâmico. No CodeIgniter, componentes são carregados e rotinas executadas somente quando preciso, ao invés de globalmente;
• Junção de componentes. Os componentes do framework são intercomunicativos, proporcionando alto índice de reutilização e flexibilidade dos sistemas baseados/derivados;
• Singularidade dos componentes. No CodeIgniter, cada classe – e respectivas funções – é autônoma, o que permite elevar o grau de utilidade e o sistema, como um todo, ter mais performance.

CodeIgniter utiliza o padrão MVC

O conhecido e “consagrado” padrão MVC foi adotado no CodeIgniter. Todo o framework é baseado em Models, Views e Controllers; mas, diferente de muitos frameworks PHP, existe realmente uma flexibilidade muito grande! Por exemplo, um Controller não está “amarrado”, necessariamente, a um View e, inclusive, pode, este Controller, chamar diferentes Models e diferentes Views – torna-se muito fácil fazer templates, por exemplo.

Classes, bibliotecas e “helpers” nativos para diversas funcionalidades

Como bom framework PHP, CodeIgniter tem seus próprios excelentes recursos nativos, utilizados através de suas bibliotecas, “helpers” e classes que já constam no framework por default:

• Calendários. Fácil criação de calendários, inclusive com criação de templates de formatação e exibição.
• Bancos de dados. De maneira simples e rápida é possível: carregar databases, executar querys, manipular resultados de consultas, realizar transações (como se fosse PDO), fazer query caching, dentre outros.
• E-mails. Enviar e-mails em protocolos diferentes (Mail, Sendmail e SMTP), envio de cópias e cópias ocultas, e-mail em texto puro ou HTML, enviar e-mail com anexos, ferramenta própria para debug, dentre outros.
• Criptografia. Funções gerais de criptografia, através do uso de hashings e chaves.
• Formulários. Criação de tags de formulário “on the fly“, tratamento de campos e informações, upload de arquivos, etc.
• Manipulação de imagens. Redimensionar, criar miniaturas, rotacionar, cortar e inserir marca d’água.
• FTP. Funções gerais de FTP, como mover, renomear, deletar, etc; e ainda uma função especial de espelhagem (“mirroring“), que permite criação dinâmica de diretórios no servidor a partir de arquivos na máquina local.
• Compactação de arquivos. Manipulação, criação, controle e edição de arquivos compactados, sendo possível criar arquivos diretamente no servidor, acrescentar files diretamente e fazer downloads dos mesmos.
• Controle de cookies sessões PHP. Manipulação e controle geral de cookies e sessões PHP, com todas suas funções, capacidades e potencialidades existentes.
• Muitas outras funcionalidades. Muitas mesmo!

Material de aprendizagem, apoio e consulta

No do site do CodeIgniter há material de aprendizagem, apoio e consulta para as pessoas que usam o framework, através do Guia do Usuário, Wiki, fóruns, vídeo-aulas e exemplos e notícias, através de um blog oficial. Além disso, também há uma comunidade de programadores que utilizam o CodeIgniter e se ajudam mutuamente.

Gostou do CodeIgniter?

Através destas breves características do CodeIgniter já dá pra ter uma noção da potência do framework! Segundo o Top 10 PHP Frameworks, o CodeIgniter é o 3º melhor framework PHP do mundo (na data de publicação deste artigo)!  Entretanto, para você decidir se gosta ou não, realmente, é preciso que você baixe o CodeIgniter e faça seus próprios testes, faça seus primeiros sites usando o framework, seus primeiros sistemas e decida por si só.

Temos certeza de que você vai gostar e, qualquer coisa, estamos aí para ajudar! ;-)

No web site oficial do CodeIgniter, vemos na definição que CodeIgniter is a powerful PHP framework. Quer dizer, presume-se que aquele que entrou no site do CodeIgniter já seja um programador PHP e saiba o que é um framework. Entretanto, algumas pessoas utilizam muito o termo “framework” e, inclusive, trabalham com frameworks, sem mesmo saber o que são, exatamente.

O que é um framework?

Existem muitas definições para “framework“, feitas por muitas pessoas diferentes; algumas muito estudadas e que desenvolveram seus próprios frameworks, outras nem tanto, mas que buscam uma definição precisa para o termo.

Segundo a Wikipédia, framework

é uma estrutura de suporte definida em que um outro projeto de software pode ser organizado e desenvolvido. Um framework pode incluir programas de suporte, bibliotecas de código, linguagens de script e outros softwares para auxiliar no desenvolvimento e unir diferentes componentes de um projeto de software.

Realmente é uma descrição bem feita e que demonstra, de forma bem satisfatória, o que é um framework. Se alguém perguntasse para mim, minha definição não seria muito diferente. Seria algo como:

Framework é um conjunto de scripts feitos por pessoas mais inteligentes que eu para eu programar de forma mais rápida, fácil e eficiente.

Falando francamente e sem muito “tecnicinismo”, um framework não passa disso mesmo: um monte de arquivos organizados, com um monte de funções, rotinas e variáveis inclusas, que servem para nos poupar o tempo de “reinventar a roda” diversas e diversas vezes, para cada novo projeto.

Quais as vantagens em usar frameworks?

Você já deve ter percebido que há muitas vantagens em se usar um framework. Mas, para ser mais explícito, algumas das vantagens em se usar frameworks são (a ordem não é por importância):

• Utilidade. O objetivo primeiro dos framworks é auxiliar no desenvolvimento de aplicações e softwares. Para tal, eles têm funcionalidades nativas das mais variadas, que ajudam você a resolver as questões sobre programação do dia-a-dia com muito mais qualidade e eficiência.
• Segurança. Os bons frameworks são projetados de modo a garantir a segurança de quem programa e, principalmente, de quem usa o que foi feito a partir dele. Não se preocupe mais com aquelas intermináveis linhas de código para evitar um SQL Injection, por exemplo; com frameworks, a parte de segurança já “vem de fábrica”.
• Extensibilidade. Os frame works permitem que você extenda suas funcionalidades nativas. Se aquela biblioteca de envio de e-mails por SMTP não contempla todas as possibilidades que você gostaria, simplesmente extenda suas funcionalidades e as use como se fossem parte do framework (na verdade, elas serão).
• Economia de tempo. O que você demoraria algumas horas ou alguns dias para fazer, você encontra pronto em um framework. Pense no quão trabalhosas aquelas funções de manipulação de imagens são; usando um framework que tenha isso, você só usa, e pronto.
• Ajuda fácil. Os que desenvolvem framworks geralmente disponibilizam material de qualidade nos web sites ou repositórios oficiais, com uma vasta documentação a respeito. Além disso, os bons frameworks sempre têm uma comunidade de desenvolvedores dispostos a se ajudarem entre si. É um prazer para os que já sabem mexer ajudar os que ainda não sabem (embora a falta de tempo também seja uma realidade).

Considerações sobre frameworks

Existem, literalmente, milhares de frameworks disponíveis para as diversas linguagens de programação existentes. É importante, antes esta imensidão de “oferta”, optar por um que atenda a suas necessidades e que seja consoante a seu método e estilo de trabalho.

Inicialmente, pode parecer que usar um frame work é pior do que fazer uma “programação pura”. Entretanto, tenha certeza: vale a pena dedicar seu tempo nisso! As vantagens vindouras de ter um projeto bem estruturado e rodando numa plataforma segura e estável, realmente compensam!

Existem dicas de como escolher um bom framework, mas, já adianto, em programação PHP, o melhor é CodeIgniter!  ;-)

Proposta

Nós, autores e mantenedores do blog, consideramos que o CodeIgniter é o melhor framework para PHP e que ele veio para ficar! As facilidades que ele proporciona no desenvolvimento; a rapidez que ele provê para a criação e manutenção de funcionalidades; as características intrínsecas que ele aprensenta; suas bibliotecas, classes e helpers nativos; é por tudo isso e muito mais que escolhemos o CodeIgniter como nosso framework para trabalhos com PHP!

Nossa proposta com este blog é tratar das diversas temáticas que envolvem o CodeIgniter, passando desde assuntos como configurações, ajustes e otimização a downloads, notícias sobre CodeIgniter, tira-dúvidas com os leitores e muito mais!

Que fique claro que não somos “gurus” em CodeIgniter, ou algo parecido. Somos apenas pessoas que gostam muito do framework e querem compartilhar o que sabem e aprender muito mais coisas, principalmente através da interação entre as pessoas que os blogs proporcionam.

Aspirações

Temos a intenção de fazer o CodeIgniter Brasil o melhor blog nacional sobre o CodeIgniter. Nossa idéia é, através de artigos, tutoriais, ajuda dos amigos e leitores, fazer com que este ambiente online seja o melhor possível – dentro das possibilidades de cada um.

E para que este objetivo aconteça, é muitíssimo importante que a contribuição dos leitores/frequentadores do blog seja uma constante. Temos certeza de que as contribuições serão várias e que teremos, mutuamente, muitos e muitos momentos para interagir e aprender por aqui!

Para já ficar ligado nos conteúdos que estão por vir, assine o feed do CodeIgniter Brasil e fique sabendo das novidades e atualizações da forma mais rápida possível!

Sucesso aos “codeigniters”!

Somos pessoas que têm seus trabalhos “oficiais” e também os “paralelos”. Uma de nossas atividades é escrever em blogs e outras publicações. Nossa intenção é colocar artigos com relativa frequencia que, esperamos, seja do agrado dos leitores.

Que todos nós, utilizadores do CodeIgniter, possamos lograr sucesso em nossas atividades e que comecem as atividades no CodeIgniter Brasil!