Vamos falar sobre o CodeIgniter 4?

Olá.

No post de hoje vou falar um pouco sobre a nova versão do CodeIgniter, a versão 4.

Enquanto eu escrevo este post, a versão do CodeIgniter 4 é a pré-alpha, ou seja, um software que é indicado somente para desenvolvedores experientes que querem apenas dar uma olhada no que há de novo, mas nunca usar para algum projeto, já que contém muitos bugs e funcionalidades que poderão sair ou mudar o jeito de utilização.

E como o CI4 está na versão pré-alpha, então, imagina-se que ainda vai levar algum tempo até chegar a beta, que é a versão onde um desenvolvedor pode até baixar o sistema de testá-lo, mas sem colocá-lo em produção.

E o PHP-FIG?

Esta é uma pergunta que muitos desenvolvedores mais experientes, e que usam outros framework fazem.

O CodeIgniter 4 vai ser um membro do PHP-FIG?

PHP-FIG (PHP Framework Interop Group) é um grupo criado em 2009 que tem como intenção ajudar a padronizar os códigos que os frameworks utilizam.

Pelo menos até o momento, o CI4 não tem intenção de se tornar um membro do PHP-FIG, já que o CI4 não irá implementar todas as recomendações sugeridas pelo grupo. Veja abaixo:

PSR-1: Basic Coding Standard

Esta recomendação cobre as classes básicas, métodos e padrões de nomes de arquivos. O style-guide do CI vai de encontro com a PSR-1 e além disso coloca também seus requisitos acima dela.

PSR-2:  Coding Style Guide

Esta PSR teve muita controvérsia quando foi lançada. O CI4 segue muitas das recomendações dela, mas não segue, e não irá seguir, todas as outras.

PSR-3: Logger Interface

A implementação de log do CI segue todas as interfaces fornecidas por esta PSR.

PSR-4: Autoloading Standard

Esta PSR fornece um método para organização de arquivos e namespaces para permitir classes com métodos de autoloading. O autoload do CI4 segue 4 recomendações desta PSR.

PSR-6: Caching Interface

O CI4 não irá tentar seguir esta PSR, já que achamos que ela exagera nas necessidades do CI4. A nova Interface SimpleCache proposta se parece mais com algo que poderíamos considerar usar.

PSR-7: HTTP Message Interface

Esta PSR padroniza uma maneira de representar as interações HTTP. Enquanto muitos dos conceitos de tornam parte da nossa camada HTTP, o CI não vai se esforçar para ser compatível com esta recomendação.

O jeito de usar o CodeIgniter 4 irá mudar?

A resposta rápida é SIM. Você vai ter que reaprender algumas coisas para poder usar o CI4.

O domínio de Orientação a Objetos ajudará bastante a você se dar bem com a nova versão do CI.

Algumas mudanças

A ideia central do CI4 continua a mesma, ser um framework fácil de aprender que implementa MVC.

O jeito de você acessar suas páginas estática, métodos, continuará igual também. Ou seja, o padrão de URI abaixo ainda funciona:

http://exemplo.com/[classe-controller]/[método-controller]/[argumentos]

Uma das mudanças dentro do controller, é que você não vai mais chamar uma view assim:

$this->load->view("nome_view");

//Agora, será assim:

echo view("nome_view", $data)

Nova estrutura de diretórios

Uma instalação padrão do CI4 possui 6 diretórios:

• /application
• /system
• /public
• /writable
• /tests
• /docs

application

Este diretório é onde todo o código da sua aplicação fica. Ele vem com uma estrutura padrão de diretórios que funcionará muito bem para a maioria as aplicações.

system

Este diretório armazena os arquivos que permitem que o framework funcione. Enquanto você possui bastante flexibilidade na maneira de usar o diretório application, os arquivos no diretório system nunca devem ser modificados.

Em vez disto, você poderia estender as classes, ou criar novas, para conseguir a funcionalidade desejada.

Todos os arquivos neste diretório ficam sob o namespace CodeIgniter

public

A pasta public trata da parte que é pública na sua aplicação, prevenindo acesso ao seu código fonte. Ela contém o principal .htaccess, index.php e qualquer outra inclusão que você deseja usar, como CSS, JavaScript ou imagens.

Esta é para ser a pasta “web root” do seu site, e seu servidor deverá ser configurado para apontar para ela.

writable

Este diretório trata de todos os diretórios que precisam de permissões de escrita enquanto sua aplicação está rodando. Ela inclui diretórios para armazenamento de arquivos de cache, logs e qualquer tipo de atualização que um usuário pode enviar a você.

Se você precisar criar novos diretórios para a sua aplicação que precisam de permissões de escrita, eles devem ser criados aqui dentro.

Isto permite que você mantenha seus outros diretórios principais sem permissões de escrita, adicionando, assim, mais uma camada de proteção à sua aplicação.

tests

Este diretório está configurado para gerenciar seus arquivos de testes. O diretório _support gerencia várias classes de exemplo e outros utilitários que você pode usar enquanto você faz seus testes.

Este diretório não precisa ser transferido para o seu servidor de produção.

docs

Este diretório armazena a documentação do CodeIgniter. A pasta user_guide contém uma cópia local do guia do usuário, e a pasta api_docs contém uma cópia local dos componentes da API do CodeIgniter.

Rotas

Nesta nova versão do CI, a parte de roteamento ganhou uma cara nova, e você deverá usá-la cada vez mais.

Aquela função de roteamento mágico, onde bastava você chamar o nome do controller e depois o método via URI sem precisar definir rotas, continuará funcionando normalmente, porém, você poderá desabilitar esta função, chamada setAutoRout(), desta maneira você terá que informar manualmente todas as rotas para suas páginas.

A desvantagem disto é que você terá que digitar um pouco a mais, e a vantagem é que seu sistema ficará mais seguro, já que todos os acessos aos seus métodos ficarão sob seu controle.

Models

As mudanças que fizeram na parte de MODELS são fantásticas, para o CI.

Digo para o CI, pois outros frameworks já implementam isso faz tempo, como o Laravel, por exemplo.

Algumas funções novas:

• Conexão automática como banco de dados
• métodos básicos de CRUD
• validação in-model
• paginação automática
• e mais…

Configurando seu Model

A classe do model tem alguns opções de configuração que podem ser definidas para permitir que os métodos da classe trabalhem perfeitamente para você.

As primeiras duas opções são usadas por todos os métodos do CRUD para determinar qual tabela usar e como nós podemos encontrar os registros requisitados:

class UserModel extends \CodeIgniter\Model
{
        protected $table      = 'users';
        protected $primaryKey = 'id';

        protected $returnType = 'array';
        protected $useSoftDeletes = true;

        protected $allowedFields = ['name', 'email'];

        protected $useTimestamps = false;

        protected $validationRules    = [];
        protected $validationMessages = [];
        protected $skipValidation     = false;
}

$table

Especifica a principal tabela com que tabela este model vai trabalhar. Esta informação se aplica as métodos de CRUD embutidos.

Você não é obrigado a trabalhar somente usando esta tabela nas suas próprias queries.

$primaryKey

Este é o nome da coluna única que identificará os registros nesta tabela. Esta coluna não precisa ser necessariamente a mesma coluna que foi definida como chave-primária no banco de dados, mas ela é usada por alguns métodos, como find() para saber em qual coluna ele deverá procurar por um valor específico.

$returnType

Os métodos do CRUD do model irão fazer um esforço por baixo dos panos e retornar para você automaticamente os dados da tabela, em vez de um objeto do tipo Result. Esta string permite que você defina o tipo de dado que será retornado.

Os valores válidos são: array, object ou um nome totalmente qualificado de uma class que será usada pelo método do objeto Result chamado getCustomResultObject().

$useSoftDeletes

Se o valor for true, então qualquer chamada ao método delete irá simplesmente definir  uma flag no banco de dados, em vez de realmente excluir o registro.

Esta função pode preservar os dados quando eles podem estar sendo referenciados em alum outro lugar, ou pode-se manter uma espécie de “lixeira” de registros que podem ser recuperados, ou simplesmente, preservar os dados como parte de uma regra de segurança.

Se for igual a true, o método find irá retornar somente linha não-deletadas, a menos que o método withDelete() seja chamado antes de chamar o método find().

$allowedFields

Esta opção é uma array que deve ser atualizada com os nomes dos campos que podem ser alterados durante um save, insert ou update.

Qualquer nome de campo além destes será descartado. Esta opção ajuda a proteger contra a entrada de dados de um formulário que serão lançados diretamente no model, resultando em um vulnerabilidades do tipo atribuição de valores em massa.

$useTimestamps

Este valor booleano determina se a data atual será automaticamente inserida em todos os inserts e updates. Se for igual a true, irá atribuir a data/hora atuais no formato especificado em $dateformat.

Esta opção precisa que existam duas colunas na tabela, chamadas “created_at” e “updated_at” com o tipo igual a DATETIME.

$dateFormat

Este valor trabalha junto com a opção $useTimestamps para certificar-se que o tipo correto de data será inserido no banco de dados. Por padrão, ele criará valores do tipo DATETIME, mas outras opções também são válidas, como: datetime, date ou int (timestamp do PHP)

$validationRules

Contém ou uma array com as regras de validação ou uma string contendo o nome de um grupo de validação.

$validationMessages

Contém uma array de mensagem personalizadas de erro que deverão ser usadas durante a validação.

$skipValidation

Se a validação deverá ser ignorada durante todos os inserts e updates. O valor padrão é false, o que significa que os dados sempre serão validados. Esta função é usada primariamente pelo método skipValidation(), mas pode ser alterado para true, porém, neste caso o model nunca irá validar os dados.

$beforeInsert, $afterInsert, $beforeUpdate, $afterUpdate, $afterFind, $afterDelete

Estas arrays permitem que você especifique métodos de callback que irão rodar nos dados na hora especificada pelo nome da propriedade.

---

Dentro do model

Veja um exemplo de método que retorna as notícias de dentro do model:

public function getNews($slug = false)
{
        if ($slug === false)
        {
                return $this->findAll();
        }

        return $this->asArray()
                    ->where(['slug' => $slug])
                    ->first();
}

Note que se for passado um texto para procura, a busca é feita por este texto, caso contrário, todos os dados são retornados, através da função $this->findAll(); do model.

Este novo método basicamente retorna todos os registros que estão na tabela, não sendo necessário a você criá-lo manualmente, já que é um método embutido do CRUD do model.

—

A explicação acima do funcionamento do model foi apenas um breve exemplo das várias mudanças que estão por vir na versão 4 do CI. Tenha em mente que como o desenvolvimento ainda está em versão pré-alpha, muita coisa pode entrar, sair, ou mudar o jeito de usar.

Roteamento

Veja abaixo um exemplo de como ficará a inserção de novas rotas na configuração:

$routes->post('news/create', 'News::create');
$routes->add('news/(:segment)', 'News::view/$1');
$routes->get('news', 'News::index');
$routes->add('(:any)', 'Pages::view/$1');

Não é tão diferente do jeito atual, mas agora note que existem métodos para cada tipo de requisição, get, add, post, etc.

Assim, dependendo do verbo HTTP que vier na requisição, você poderá direcionar o usuário para um local específico, seguindo as regras RESTful.

Services

Todas as classes que vêm com o CodeIgniter 4 são fornecidas como “services”.

O que muda aqui basicamente é que em vez de você precisar digitar um código para carregar uma classes, as classes que serão chamadas estão definidas dentro de um arquivo de configuração muito simples.

Este arquivo atua como se fosse uma fábrica para criar novas instâncias das classes desejadas.

Um exemplo rápido para deixar as coisas mais claras.

Imagine que você precisa recuperar uma instância da classe Timer.

Um jeito simples de fazer isto é criando uma nova instância daquela classe, assim:

$timer = new \CodeIgniter\Debug\Timer();

E isso iria funcionar muito bem. Até você decidir que você quer agora usar uma outra classe de tempo no seu lugar. Talvez por que seja uma classe que seja melhor do que a original.

Para fazer isto, você vai ter que localizar todos os lugares na sua aplicação onde você usou a classe timer, e você já deve ter imaginado como isso pode ser muito trabalhoso de fazer.

É aí que entram os services do CodeIgniter 4.

Em vez de criar uma instância você mesmo, foi criada uma classe principal que cria as instâncias para gente. Esta classe é mantida de uma forma muito simples.

Ela só contém um método para cada classe que nós querermos usar como um serviço. Este método irá retornar, tipicamente, uma instância compartilhada daquela classe, passando qualquer dependência que possa existir nela.

Então, nós poderíamos substituir nossa código de criação do timer com o código que chama a nova classe:

$timer = \Config\Services::timer();

Quando você precisar alterar a implementação usada, você pode mudar somente o arquivo de configuração, e a alteração ocorrerá automaticamente por toda a sua aplicação sem que você tenha que modificar nada a mais.

—

Bom é isto. Não vou me alongar muito aqui pois há bastante coisa que vai mudar nesta nova versão. Porém, achei interessante mostrar algumas alterações que achei mais importantes aqui neste post.

Sempre que houver alguma novidade no desenvolvimento do CI4, eu postarei aqui no blog.

E se você está se perguntando se no futuro eu irei fazer um curso de CodeIgniter 4, pode apostar que sim.

Seria interessante você deixar nos comentários abaixo o que você gostaria de aprender em um curso de CodeIgniter 4. 🙂

Então fique ligado no blog ou na Fanpage no Facebook para saber das novidades.

Fabio