Archive for 'Passos Iniciais'

Diferença entre helper, library e plugin no CodeIgniter

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.

Controllers no CodeIgniter

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

Controllers no CodeIgniter

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

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

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

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

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

Estrutura de um Controller no CodeIgniter

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

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

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

O nome da classe deve iniciar com letra maiúscula

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

class Noticias extends Controller
{
}

Isso é errado:

class noticias extends Controller
{
}

Deve haver um construtor

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

1
2
3
4
5
6
7

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

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

O arquivo deve ter o mesmo nome da classe

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

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

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

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

Funções em um Controller no CodeIgniter

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

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

1
2
3
4
5
6
7

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

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

Funções privadas em controllers

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

function _funcaoqualquer()
{
  // códigos
}

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

Definindo um Controller padrão

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

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

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

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

E isso é tudo sobre controllers no CodeIgniter?

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

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

URLs no CodeIgniter

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

Estrutura de URL no CodeIgniter

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

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

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

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

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

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

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

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

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

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

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

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

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

Removendo o segmento “index.php”

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

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

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

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

Adicionando sufixo ao URL

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

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

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

Trabalhando com Query Strings

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

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

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

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

index.php?c=estatisticas&m=mostrar

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

Conclusão sobre URLs no CodeIgniter

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

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

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

Categorias

• Diversos (3)
• Passos Iniciais (11)