CodeIgniter: Requisitos de Servidor e Licença de Uso

Até agora estávamos em uma “introdução geral”, falando genericamente sobre o que são framewoks, um pouco sobre padrões de projeto, o padrão MVC e uma palhinha sobre o próprio CodeIgniter, mostrando que ele é um framework PHP ágil, robusto e de alta performance e mostramos 10 razões de porque CodeIgniter arrasa!

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

10 razões de porque CodeIgniter arrasa

De vez em quando é possível encontrar em algum artigo de blog ou discussão em fóruns a pergunta sobre qual é o melhor framework para PHP. Todos os frameworks têm seus pontos positivos e negativos, mas a verdadeira resposta para essa pergunta, é que depende do programador. Cada programador tem um estilo diferente e diferentes prioridades quando se trata de adotar uma tool kit para usar na construção de seus aplicativos.

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).

MVC (Model – View – Controller)

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!

Pesquisar por:

Categorias

• Configurações (1)
• Dicas (1)
• Diversos (3)
• Passos Iniciais (16)