Programadores PHP são bem divididos na comunidade entre os que gostam e os que não gostam de usar Frameworks, basta acompanhar listas de discussões, fóruns ou até mesmo entres os programadores PHP que conhecemos – sim, porque existem tantos programadores PHP, que todos conhecem ao menos um programador dessa linguagem.
No lado dos desenvolvedores que não são a favor de uso de Frameworks, têm-se argumentos como:
- Velocidade: desenvolver PHP da forma convencional, sem Frameworks, torna o sistema mais rápido, e a maioria dos Frameworks deixam o sistema mais pesado a cada nova funcionalidade.
- Complexidade: Frameworks necessitam de uma nova aprendizagem, muitas vezes diversos comandos mudam totalmente, tornando o desenvolvimento mais difícil, impossibilitando desenvolvedores de nível júnior a desenvolverem de forma rápida.
- Documentação: todos sabem que o site oficial do PHP é excelente e que há ali uma vasta documentação, com exemplos e comentários de qualquer comando no idioma oficial, bem como bastante coisas já em português também.
- Flexibilidade: esse é, talvez, o principal argumento utilizado, já que com a programação em PHP convencional, vai da criatividade e necessidade do desenvolvedor a forma de se resolver os diversos problemas do sistema. Pode-se, por exemplo, fazer algoritmos para as funções já existentes e usá-las ao invés das padrões; pode-se criar queryies de banco de dados exatamente como se faz no banco de dados ou adicionar classes para a manipulação dessas queries, entre outras coisas.
Já do lado dos desenvolvedores são a favor de uso de Frameworks, alguns argumentos são:
- Velocidade do desenvolvimento: um dos principais objetivos dos Frameworks é agilizar o desenvolvimento
- Criação de um padrão de desenvolvimento a ser seguido: de uma forma ou de outra, os Frameworks ajudam na padronização de códigos e, consequentemente, na manutenção do projeto por outras pessoas, além dos próprios criadores iniciais.
- Manipulação de banco de dados: com o uso dos principais Frameworks, temos uma facilidade muito maior na criação de query’s de banco de dados para consulta, inclusão, exclusão, etc.
- Recursos práticos para tarefas diversas
Frameworks vêm com uma série de ferramentas úteis para tarefas genéricas. Vão desde manipulação de urls para criação de site amigável para dispositivos de busca, até gerador de formulários que reproduzem exatamente uma tabela de banco de dados previamente criada.
O CodeIgniter reúne o melhor dos mundos, pois ele vem com todos os recursos de um bom Framework, mas sem deixar o desenvolvimento totalmente dependente apenas dos recursos dele. Além do mais, todas as classes podem ser redefinidas, ou seja, os métodos padrão de cada recurso podem ser sobrescritos para uma forma diferente da que já existe, de uma forma bem simples.
Para utilizar o Framework, basta baixar o arquivo diretamente do site oficial, descompactá-lo dentro do diretório root do servidor e renomear a pasta para algum nome qualquer. Depois disso, o CodeIgniter criará uma estrutura simples inicial com uma página de exemplo, basta chamar http://localhost/NOME_DO_DIRETORIO e verá uma página como esta:
A própria página inicial te explica onde estão os arquivos para encontrar essa página.
Aqui veremos como se faz o mais simples, que é a forma em que está estruturado o Framework e como fazer para colocar códigos comuns de PHP no CodeIgniter.
O CI trabalha dentro do conceito de MVC, ou seja cada camada da aplicação tem suas responsabilidades e localizações físicas diferentes. Em uma explicação mais grosseira, os arquivos que iremos manipular (no início, já que pode-se fazer diversas adaptações que vou mostrar em outros artigos), estão dentro do diretório “DIRETORIO_ROOT/system/application”. Os arquivos de fora dessa pasta são arquivos do CI, como bibliotecas e configs.
Agora, como a imagem acima diz, a página correspondente a essa mensagem de “bem-vindo” está localizada dentro da pasta “system/application/views/welcome_message.php” e ela é acionada a partir de um controller localizado em “system/application/controllers/welcome.php”.
Essa característica de padronizar os arquivos em diretórios específicos ajuda na manutenção do código, pois a própria url do sistema irá ajudar a encontrar um arquivo para ser modificado.
O controller welcome foi acionado automaticamente, mas só por conveniência e para definir algum arquivo inicial e padrão do framework. Para alterar o nome do arquivo inicial do projeto, basta abrir o arquivo de configuração, localizado em “system/application/config/routes.php” e trocar o valor da variável.
$route['default_controller'] = "welcome"; para o nome do arquivo que será o controller inicial do sistema. Mas vamos continuar com o arquivo sendo o padrão do CI. Abrindo o controler "welcome.php" veremos uma classe como a seguinte: class Welcome extends Controller { function Welcome() { parent::Controller(); } function index() { $this->load->view('welcome_message'); } }
A primeira coisa que podemos dizer sobre isso é que a classe deve seguir o padrão de nomenclatura, sendo que o nome da classe precisa ser igual ao nome do arquivo, mas sem o .php e com a primenta letra em maiúscula. Caso tivéssemos um controller chamado usuario.php, teríamos uma classe Usuario.
Pode-se notar, também, que a classe estende a classe Controller, é essa classe que fará grande parte das mágicas do CI.
A primeira função escrita com o mesmo nome da classe é o construtor da classe (para quem está acostumado com orientação a objetos, não será difícil), essa função é obrigatória e precisa ter essa chamada ao construtor da classe pai.
A próxima função é a index, ela serve para ser a página inicial da sua funcionalidade. Não é obrigatória, mas é bem útil para diminuir o tamanho das urls.
Por exemplo, caso a função welcome não estivesse sendo chamada automáticamente, se não estivesse no route.php, ou mesmo com ela lá no routes.php, mas você queira acessar o controller como um controller comum, a url para acessar é:
seudominio/index.php/welcome
Se a classe tivesse outro nome, por exemplo, usuário, seria:
seudominio/index.php/usuário
A função index funciona como se fosse um index.php ou index.html no servidor, ela define o que vai ser feito em caso de o usuário não passar nada na url depois do nome da classe (no caso welcome).
O conteúdo da função index é apenas:
$this->load->view(‘welcome_message’);
Essa função tem por objetivo carregar algum arquivo da camada view do projeto. O parâmetro interno que está sendo usado é “welcome_message”, ou seja, esse é o nome do arquivo (tirando-se a extensão .php) que está dentro da pasta de arquivos da camada view (“system/application/views”).
Por último, vamos criar uma “funcionalidade” nova para a classe welcome, que seria listar. Essa funcionalidade poderá ser vista a partir da url:
seudominio/index.php/welcome/listar
Para criá-la, adicione no controller a seguinte função abaixo da função index já existente:
function listar() { $param["valor1"] = 123456; $param["valor2"] = "exemplo valor 2"; $param["valor3"] = Array ("A"=>'1', "B"=>777); $this->load->view('listar', $param); }
Veja que estamos adicionando mais um parâmetro à função view: além de passar a String com o nome do view correspondente (listar), estamos passando também um array, criado nas três linhas anteriores. Esse array possui um valor numérico dentro da chave “valor1”, um valor de String dentro da chave “valor2” e um Array com uma chave A e valor de caracter e uma chave B com valor numérico.
Esse segundo parâmetro é que chega na view para ser manipulada pelo template.
Agora o template listar.php dentro da pasta views poderia ser como esse:
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
listar!
echo $valor1; echo " "; echo $valor2; echo " "; print_r($valor3); ?>
Entrando na url
seudominio/index.php/welcome/listar
O resultado seria como a tela a seguir:
Esse artigo pretendia apenas mostrar um exemplo simples de utilização do CodeIgniter e como funciona sua estrutura interna básica. Não entrei em detalhes em funções de banco de dados, nem no uso de helpers. Nos próximos artigos vou passar por esses tópicos.