Archive for 'Passos Iniciais'

Views no CodeIgniter

Relembrando nossa saga de explicações básicas, vimos como é o funcionamento do padrão MVC, os controllers (e como funciona o esquema de URLs no Codeigniter em função dos controllers) e models. Chegou, então, o momento de estudarmos um pouco sobre  views no CodeIgniter!

Views no CodeIgniter

Como foi mostrado no referido artigo sobre Model – View – Controller,

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, são exibida.

No artigo sobre controllers, foi dado o exemplo de uma função matemática que, conforme o URL passado, soma 2 números e exibe o resultado em tela através da função echo(). Mas o exemplo foi somente para ilustrar como é o funcionamento geral dos controllers. Na prática, tudo o que se vai mostrar a quem utiliza o site/software deve ser feito através de views!

Afinal de contas, o padrão MVC foi criado para, justamente, manter em “compartimentos separados” a lógica do aplicativo, o contato com os dados usados e a exibição de o que quer que seja a quem o utiliza. Portanto, views foram idealizados para exibirem todas as informações/processamento que ocorra entre models-controllers. Reforçando: tudo deve ser exibido através de views!

Para ficar claro, podemos dizer que as principais funções de um view, através de invocações de métodos e ventos, são:

• “Renderizar” (exibir) informações vindas dos models/controllers;
• Requisitar atualizações aos models/controllers;
• Enviar ações de usuários (através de inputs) a models/controllers;

Cada vez mais é possível observar a eficiência e praticidade do padrão MVC e perceber que cada um preciso e trabalha em conjunto ao outro. Models, Views e Controllers, cada um tem uma razão de existir e desempenha um papel diferentes, todos em conjunto para viabilizar um desenvolvimento eficiente e organizado.

Funcionamento de Views no CodeIgniter

Seguindo a “linha” dos outros artigos, este tópico deveria ser “Estrutura de um View no CodeIgniter”, mas os views são formados simplesmente por XHTML e CSS. Views são a parte que é vista pelos visitantes/usuários, e, na web, isso é desenvolvido e apresentado usando as respectivas linguagem de marcação e folhas de estilo. Então, views podem ser uma página completa ou um fragmento de uma página, como um cabeçalho, um rodapé, uma barra lateral e assim por diante.

Vamos, então, passar a alguns pontos referentes ao funcionamento de views no CodeIgniter.

Armazenamento de Views

Os views devem ser armazenados em application/views. Simplesmente dê um nome a seu view e armazene neste diretório – muitos views são diretamente ligados a um controller; sendo este o caso, ou não, é importante dar nomes aos views que remetam facilmente a qual função ou conjunto de funções ele está refere. Por exemplo: application/views/about.php

Também é possível estruturar e refinar mais a organização de views. O CodeIgniter permite que se criem subníveis de diretórios dentro do diretório padrão de views. Então, por exemplo, é possível armazenar arquivos de views em uma estrutura do tipo: application/views/includes/head.php ou application/views/blog/widgets/advertising.php.

Carregando um(a) view

Para carregar um(a) view em um controller:

1

$this->load->view('about'); // sem extensão, se for ".php"

Para o caso de organização em subdiretórios, basta especificar onde o view se encontra:

1

$this->load->view('includes/head.php');

Carregando múltiplos views

Para carregar múltiplos views, basta chamar um por linha e o CI faz a “montagem” em uma só exibição:

1
2
3

$this->load->view('includes/head.php');
$this->load->view('body.php');
$this->load->view('includes/footer.php');

Passando informações para views

É possível entender o poder do CodeIgniter e sua facilidade de uso ao se passar uma informação dinâmica para ser exibida em um view! Basta carregarmos essa informação em um array ou objeto e passar essa informação no momento de carregamento do view no controller. Por exemplo:

1
2
3
4
5
6

$data = array(
    'title'   => 'Sobre',
    'content' => 'Texto da página sobre',
);
 
$this->load->view('about', $data);

Nisso, as informações do array $data serão passadas ao view. Para exibir essas informações na view, simplesmente é preciso tratar como se cada um dos itens do array fosse uma variável à parte, da seguinte maneira:

1
2

<h1><?php echo $title ?></h1>
<p><?php echo $content ?></p>

Fazendo loopings nos views

Para fazer loopings em views, também é simples. Por exemplo, vamos supor que tenhamos carregado a seguinte informação em um controller:

1
2
3
4
5

$data['todo_list'] = array('Lavar os pratos', 'Limpar a casa', 'Ligar para a pizzaria');
 
$data['title'] = "Lista de afazeres";
 
$this->load->view('afazeres', $data);

Então, no respectivo view, teríamos:

1
2
3
4
5
6
7

<h1><?php echo $title ?></h1>
 
<ul>
    <?php foreach($todo_list as $item): ?>
        <li><?php echo $item ?></li>
    <?php endforeach ?>
</ul>

Existe, ainda, uma maneira de passar o “data” para os views como string puro. Mas, como isso não é tão comum de ser feito, fica para um próximo artigo, mais específico.

Conclusão sobre Views no CodeIgniter

Obviamente isso não é tudo o que se tem para saber sobre views no CodeIgniter. Mas esse “básico” sobre views, juntamente com o conteúdo sobre models e controllers, já passa uma noção bem legal sobre o poder do CodeIgniter.

Para quem não conseguiu juntar as peças sobre MVC no CodeIgniter, não se preocupe: no próximo artigo vamos colocar models, views e controllers para trabalhar juntos e você vai ver um dos motivos de porque o CodeIgniter é o melhor framework PHP! ;-)

Models no CodeIgniter

Já vimos que Controllers no CodeIgniter são responsáveis por controlar o fluxo dos programas, que contêm as regras de negócio. Já no artigo sobre MVC, também vimos que Models no CodeIgniter são responsáveis pelas quais o CRUD acontece, ou seja, sempre que dados forem criados, selecionados, atualizados ou deletados, seja num banco de dados, arquivo XML ou onde quer que estes dados estejam armazenados, então é com o Modelque temos que trabalhar.

Models do CodeIgniter

É possível, sim, desenvolver sites com CodeIgniter trabalhando somente com Controllers e Views; entretanto, este seria um uso “castrado” do framework, já que muito de seu poder reside na capacidade de abstração e tratamento de informações vindas de bancos de dados. Explicava a devida importância dos Models no CodeIgniter, vamos aprender um pouco mais a respeito.

Ao limitarmos nosso desenvolvimento a somente projetos “estáticos”, sem o poderoso recurso de armazenagem de dados, na verdade não conseguiremos desenvolver grandes feitos quando o assunto é internet. Realmente existem nichos de atuação para captação de recursos que dispensam uso de BDs, mas o foco de atuação deste blog não é este.

Então, regra geral, sempre que pensarmos em CodeIgniter, devemos pensar em uso de bancos de dados para armazenagem das informações, seja na feitura de um blog, site, e-commerce ou qualquer outro sistema online.

Foi visto no artigo sobre MVC que os Models possuem as seguintes características principais:

• Encapsula o estado da aplicação;
• Realiza e responde a consultas no banco de dados.

Estrutura de um Model no CodeIgniter

Models no CodeIgniter ficam armazenados em application/models, aceitando, também, estruturação em subdiretórios, caso seja preciso.

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 model no CodeIgniter (para fins didáticos, “Blog”) é a seguinte:

1
2
3
4
5
6

class Blog extends Model {
    function Blog()
    {
        parent::Model();
    }
}

E, a partir dessa estrutura-modelo, deduz-se as seguintes regras de sintaxe:

• Nomes de classes de models devem ter a primeira letra em maiúsculo;
• Nomes de classes de models, com exceção da primeira letra, devem ser em minúsculo;
• Os models devem extender a classe base “Model” através de uma função com mesmo nome da classe;
• O arquivo da classe deve ter o mesmo nome da classe em minúsculo (ex., application/models/blog.php).

Carregando um Model

Comumente, models são carregados a partir de funções nos controllers do software. Genericamente, um model é carregado através da seguinte função:

1
2
3

 // se o arquivo do model estiver em subdiretório,
 // basta indicar o caminho no parâmetro
$this->load->model('Model');

Depois de carregado o model, suas funções são acessadas a partir da seguinte sintaxe:

1

$this->Model->function();

Opcionalmente, é possível especificar um “apelido” para um model, apelido este que, se especificado será usado para a chamada das funções:

1
2

$this->load->model('Model', 'apelido');
$this->apelido->function();

Carregar models automaticamente (auto-loading Models)

É bastante comum um model ser tão útil ao ponto de precisar ser usado em praticamente toda uma aplicação. Para esses e outros casos, o CodeIgniter permite que um ou mais models sejam carregados automaticamente, juntamente com a inicialização do sistema.

Para carregar models automaticamente, abra o arquivo application/config/autoload.php, procure a seção “Auto-load Models” e especifique no array qual(is) model(s) você deseja que sejam carregados automaticamente. Por exemplo:

1

$autoload['model'] = array('blog', 'forum', 'chat');

Conectando ao Banco de Dados

Quando um model é carregado, não há conexão automática ao banco de dados. Isso é algo que deve ficar bem claro, pois gera enorme dúvida e, se não observado, pode parecer que está acontecendo um erro na lógica do programa – consequentemente, tem o potencial de fazer você desperdiçar horas de esforço atrás de um erro inexistente…

Existem diversos métodos de conexão ao banco de dados; para o momento, saiba que, para se conectar ao banco de dados de sua aplicação, você deve passar um parâmetro à função de carregamento do model. Fica assim:

1

$this->load->model('Model', '', TRUE); // parâmetro vazio é o "apelido"

Esse terceiro parâmetro indica que a conexão ao banco de dados deve ser feita utilizando as informações de BD contidas no arquivo application/config/database.php. Isso é o mais comum e prático de ser feito. Entretanto, há casos ou pode ser de sua preferência, especificar, no próprio controller, quais as informações necessárias para a conexão.

Nesse caso, ao invés de “TRUE”, o último parâmetro conterá o array (com nome de sua preferência) com esses dados:

1
2
3
4
5
6
7
8
9
10
11

// Os parâmetros mais "incomuns" serão explicados em artigos futuros
$config['hostname'] = 'localhost';
$config['username'] = 'username';
$config['password'] = 'password';
$config['database'] = 'database';
$config['dbdriver'] = 'mysql';
$config['dbprefix'] = '';
$config['pconnect'] = FALSE;
$config['db_debug'] = TRUE;
 
$this->load->model('Model', '', $config);

No próximo artigo serão explicados os diversos meios de o CodeIgniter se conectar a um (ou mais de um) bancos de dados. Não percam! ;-)

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.

Categorias

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