Atenção!! Este artigo foi escrito em cima da versão 1 do Codeigniter. Para detalhes de como usar com a versão 2 do framework clique aqui.

Continuando a parte 1 deste post.
Se você perdeu a primeira parte clique aqui para ler a primeira parte.

5 – Construindo sua View

Sua View deve ser feita normalmente, como voce já está acostumado a fazer, com o nome que você colocaria normalmente.
Apenas com o conteúdo que muda de uma página para outra.

O HTML que você colocar aqui na View irá substituir a variável {content_for_layout} que definimos no layout acima.
Vou colocar nessa nossa view de exemplo apenas um título e um parágrafo para demonstrar.
Ficando assim:

<h1>Titulo VIEW</h1>

<p>Paragrafo teste teste teste teste.</p>

Chamei essa view de home.php.

6 – Desenvolvendo a Classe

Quando definimos nosso Hook no passo 2, setamos que a pasta onde ficaria nossa classe seria a pasta hooks que vem por padrão no projeto do CodeIgniter.

Vamos criar nossa classe dentro dessa pasta, e, com o nome que também especificamos na definição do Hook que foi Layout.php
Se você não seguiu o exemplo, faça suas devidas adaptações.

A classe é um pouco extensa, leia com atenção.
Para ajudar ela está com os comentários do próprio Mozart Petter.

// Padrao do CI para não acessar a Classe direto pelo Browser
<?php if (!defined('BASEPATH')) exit('No direct script access allowed');

/**
 * Layout Class
 *
 * @package hooks
 * @description Implementa as views do tipo layout no framework.
 */

class Layout
{

public $base_url;

/**
* Metodo que executa as implementacoes.
* Este metodo e chamado atraves do arquivo hooks.php
* na pasta config.
*
* @return
*/
public function init()
{
// Instancia do CI.
$CI =& get_instance();

// Definindo o base_url.
$this->base_url = $CI->config->slash_item('base_url');

// Pegando a saida que o CI gera normalmente.
$output = $CI->output->get_output();

// Pegando o valor de title, se definido no controller.
$title = (isset($CI->title)) ? $CI->title : '';

// Links CSS definidos no controlador.
$css = (isset($CI->css)) ? $this->createCSSLinks($CI->css) : '';

// Links JS definidos no controlador.
$js = (isset($CI->js)) ? $this->createJSLinks($CI->js) : '';

// Se layout estiver definido e a regexp nao bater.
if (isset($CI->layout) && !preg_match('/(.+).php$/', $CI->layout))
{
$CI->layout .= '.php';
}
else
{
$CI->layout = 'default.php';
}

// Definindo caminho completo do layout.
$layout = LAYOUTPATH . $CI->layout;

// Se o layout for diferente do default, e o arquivo nao existir.
if ($CI->layout !== 'default.php' && !file_exists($layout))
{
// Exibe a mensagem, se o layout for diferente de '.php'.
if ($CI->layout != '.php') show_error("You have specified a invalid layout: " . $CI->layout);
}

// Se o arquivo layout existir.
if (file_exists($layout))
{
// Carrega o conteudo do  arquivo.
$layout = $CI->load->file($layout, true);

// Substitui o texto {content_for_layout} pelo valor de output em layout.
$view = str_replace('{content_for_layout}', $output, $layout);

// Substitui o texto {title_for_layout} pelo valor de title em view.
$view = str_replace('{title_for_layout}', $title, $view);

// Links CSS.
$view = str_replace('{css_for_layout}', $css, $view);

// Links JS.
$view = str_replace('{js_for_layout}', $js, $view);
}
else
{
$view = $output;
}

echo $view;
}

/**
* Gera os links CSS utilizados no layout.
*
* @return void
*/
private function createCSSLinks($links)
{
$html = "";

for ($i = 0; $i < count($links); $i++)
{
$html .= "<link rel='stylesheet' type='text/css' href='" . $this->base_url . CSSPATH . $links[$i] . ".css' media='screen' />n";
}

return $html;

}

/**
* Gera os links JS utilizados no layout.
*
* @return void
*/
private function createJSLinks($links)
{
$html = "";

for ($i = 0; $i < count($links); $i++)
{
$html .= "<script type='text/javascript' src='" . $this->base_url . JSPATH . $links[$i] . ".js'></script> n";
}

return $html;
}

}

7 – Fazendo as chamadas no Controller

Chegou o momento final!
É hora de juntar tudo isso que fizemos até agora.

A construção do seu controller é normal, como você está acostumado, mas temos que inserir algumas variáveis globais nele.

• Uma para o Layout default do controller, para que você não precise fazer a mesma definição várias vezes.
• Uma para o título, onde você pode definir um default para todos as páginas que vão surgir desse controller mas, o interessante é estar um título por página.
• Outra para guardar um Array dos CSS’s que você vai usar na página.
• E por último, outro Array para guardar os JavaScripts que você vai usar na página.

Vejamos como fica.
Acompanhe pelos comentários.

<?php

/**
 *
 */
class Principal extends Controller
{

/**
* Layout default utilizado pelo controlador.
*/
public $layout = 'default';

/**
* Titulo default.
*/
public $title = '::: Titulo default :::';

/**
* Definindo os css default.
*/
public $css = array('default');

/**
* Carregando os js default.
*/
public $js = array('home');

/**
* Construtora.
* @return
*/
function Principal()
{

parent::Controller();

}

// Metodoo index
function index()
{
// Carregando a view.
$this->load->view('home');
}

// Metodo teste
function teste()
{
//Title
$this->title = '::: TESTE Título :::';

//CSS
$this->css = array('test');

//JS
$this->js = array('jquery');

// Carregando a View
$this->load->view('teste');
}

}

?>

Vamos reparar no seguinte.
Há dois métodos nesse controller que vão chamar páginas diferentes, o index e o teste.

Para o index não definimos nada de Layout, Titulo, CSS ou JS.
Ou seja, vai vir tudo do valor default que usamos quando definimos as variáveis globais.

Já no método teste, por algum motivo precisamos de um CSS, um JS e um Título diferente.
Então redefinimos esses valores no nosso método com o que precisamos.

A gente poderia ter definido um outro Layout caso tivesse a necessidade, da mesma forma com que fiz com esses valores.
Aí, claro, teria que criar um outro Layout na pasta layouts.

UPDATE 20 DE NOVEMBRO DE 2010
Detalhe importante observado pelo Diego Felix (@diegofelix), que comentou esse detalhe abaixo nos comentários, no dia 16 de setembro desse mesmo ano.

Eu tenho como costume em meus projetos com CI, retirar a pasta system no qual ele vem por padrão.
Faço então a alteração da variável $system_folder no arquivo de configuração e tudo segue sem problemas.

Exceto esse tutorial, que não leva em consideração essa pasta system.
Você tem duas opções para consertar isso:

Primeiro:
No local onde são definidas as variáveis contantes, adicionar sua pasta system antes de $application_folder.
Exemplo: define(‘LAYOUTPATH’, ‘system/’ . $application_folder.’/layouts/’);

Particularmente acho essa solução acima atrasada, por deixar o projeto estático.
Se ocorrer de você alterar a pasta system, terá que alterar nesse local também. Chato.

Segundo:
Seguindo essa linha de raciocínio, de não deixar o projeto estático, prefiro fazer o seguinte:
No local onde são definidas as variáveis constantes, adicionar a variável $system_folder.
Exemplo: define(‘LAYOUTPATH’, $system_folder . ‘/’ . $application_folder.’/layouts/’);

Mas há um detalhe.
No arquivo index.php, em torno da linha 53, é adicionado a variável $system_folder o seu caminho completo do servidor. Isso, claro, vai gerar problemas para o projeto.
O que eu faço então é pegar as variáveis constantes que usam a pasta system, e jogar antes desse bloco.
Se você seguir pelo projeto exemplo, verá que as coloquei logo depois do comentário “END OF USER CONFIGURABLE SETTINGS”.

Feito isso, caso você altera sua pasta system, basta alterar no local de sempre para o projeto continuar funcionando.

Pessoal é isso!
Fazia tempo que queria escrever sobre isso, espero que ajude a galera por aí.
Dúvidas podem mandar sem problemas, vou responder no que estiver a meu alcance.

Se você teve dificuldades, baixe o projeto pronto aqui e dê uma olhada mais de perto.

Agradeço novamente ao Mozart Petter, grande Brother, que implementou essa solução que uso até hoje em meus projetos. E, como sempre, também ao pessoal que garante minhas 30 visitas diárias, Valeu!

É isso pessoal.
Até a próxima!!!

Atenção!! Este artigo foi escrito em cima da versão 1 do Codeigniter. Para detalhes de como usar com a versão 2 do framework clique aqui.

Vejo muitos desenvolvedores criticarem o CodeIgniter por ele não utilizar o conceito de Layout ou ter um Template Engine dentro dele.

Template engine ou o conceito Layouts , falando em um exemplo rápido e prático seria mais ou menos o seguinte:
Pense que você tem um topo e um rodapé que nunca mudam no seu portal.
Ou seja, muda apenas o meio das páginas. Veja a figura abaixo.

E aí? Você vai ter que colocar esse topo e esse rodapé em todas as páginas que você chamar?
Ou você é malandro e vai fazer um include dentro das telas?

O Include seria uma solução interessante mais uma Template Engine faria isso sozinho para você.

Pra quem não conhece nenhuma solução para isso, o Smarty é uma template Engine das mais conhecidas no mundo do PHP.
Você tem uma lista com outras sugestões de Templates Engine nesse link da web Resources
Outros frameworks como o CakePHP tem uma solução dentro dele que faz esse trabalho.

Nesses tempos que desenvolvo em CodeIgniter já vi bizarrices do tipo colocar o Smarty dentro do CodeIgniter ou trazer bibliotecas de outras frameworks para o Core do CodeIgniter.

Mas podemos estender o Core do Framework e fazer ele trabalhar junto com a gente sem precisar de muitas manobras e malabarismos. Na documentação do CodeIgniter achamos essa prática com o nome de Hooks ou se preferir o português ganchos.

Há alguns anos um cara que considero um dos Gurus do desenvolvimento, Mozart Petter, o qual tive a honra de trabalhar junto, pesquisou uma solução nesse sentido para que não precisássemos abandonar o CodeIgniter.

Você encontra vários links pesquisando no google por Layouts in CodeIgniter, onde destaco o seguinte Blog http://hasin.wordpress.com/2007/03/05/adding-yield-codeigniter/

Abaixo vou colocar uma solução em 7 passos para você implementar isso em seu projeto de CI.
É importante que você procure entender em cada passo como o CodeIgniter vai visualizar isso tudo.
*Não se deixe confundir. É fácil. Se ficar difícil há algo errado, volte e reveja os passos.

Como os códigos são muito extensos, vou dividir em dois posts.
Parte 1 – Esse (passo 1 ao 4) e Parte 2 (passo 5 ao 7) que você acessa aqui.

Para quem não estiver com muita paciência, estou disponibilizando também um exemplo pronto de tudo funcionando que você pode baixar aqui.
Apenas confira se o .htaccess serve para o seu servidor ou máquina.

DETALHE IMPORTANTE:
Esse projeto de exemplo foi atualizado no dia 20 de novembro de 2010. Sugestão do Diego Felix (@diegofelix).
Confira a explicação da alteração no final da segunda parte ou clicando aqui.

1 – Habilitando o Codeigniter para estender o Core

A primeira coisa a fazer é habilitar o codeIgniter para estender o Core, permitir os hooks.
Isso é feito no arquivo config.php dentro da pasta config.
Procure a variável $config['enable_hooks'] e troque seu valor para TRUE, ficando como abaixo.

/*
|--------------------------------------------------------------------------
| Enable/Disable System Hooks
|--------------------------------------------------------------------------
|
| If you would like to use the "hooks" feature you must enable it by
| setting this variable to TRUE (boolean).  See the user guide for details.
|
*/
$config['enable_hooks'] = TRUE;

Pronto! Próximo passo.

2 – Definindo um Hook

Dentro da pasta config temos um arquivo onde deve ser feitas as definições dos hooks que você quer utilizar.
É o arquivo hooks.php. Para cada hook é preciso definir um array com alguns parâmetros para que o CodeIgniter saiba o que fazer.

Importante: O índice do array vai funcionar apenas como nome do seu hook. Você não vai usá-lo em nenhum lugar a princípio.

Para o nosso Hook vamos definir.

• O nome da Classe que você precisa.
• O nome do método da classe que você deseja chamar.
• O nome do arquivo onde está desenvolvida a classe.
• O directório onde ela se encontra.

Fica da seguinte forma:

$hook['display_override'][] = array('class' => 'Layout',
'function' => 'init',
'filename' => 'Layout.php',
'filepath' => 'hooks');

Esses itens podem variar de acordo com o que você quiser ou precisar fazer.
O manual é uma grande referência para te ajudar com isto e traz alguns detalhes que não abordo aqui.

Certo! Você habilitou e definiu um Hook, ou gancho. Vamos para o próximo passo.

3 – Adicionando algumas constantes necessárias

No arquivo index da aplicação são definidas algumas constantes que ajudam no desenvolvimento da nossa aplicação, como por exemplo,
a extensão dos arquivos que serão usados, constante EXT, e o BASEPATH que traz o caminho da pasta do sistema.

Vamos adicionar aqui mais 3 constantes que vai nos facilitar lá na frente quando formos fazer nossa classe.

• LAYOUTPATH – Caminho onde ficará os layouts que construirmos.
• JSPATH – Caminho onde ficará os arquivos com javascript.
• CSSPATH – Caminho onde ficará os arquivos de estilo. CSS.

Ficando da seguinte forma:

/*
|---------------------------------------------------------------
| DEFINE APPLICATION CONSTANTS
|---------------------------------------------------------------
|
| EXT		- The file extension.  Typically ".php"
| SELF		- The name of THIS file (typically "index.php")
| FCPATH	- The full server path to THIS file
| BASEPATH	- The full server path to the "system" folder
| APPPATH	- The full server path to the "application" folder
|
*/
define('EXT', '.php');
define('SELF', pathinfo(__FILE__, PATHINFO_BASENAME));
define('FCPATH', str_replace(SELF, '', __FILE__));
define('BASEPATH', $system_folder.'/');
define('LAYOUTPATH', $application_folder.'/layouts/');
define('JSPATH', $application_folder . '/js/');
define('CSSPATH', $application_folder . '/css/');

Reparem que usei a variável $application_folder, que é definida no mesmo arquivo, para completar o caminho das minhas constantes.
Você pode e deve mudar isso de acordo com seu projeto.

Essas constantes vão facilitar também para caso você precise mudar o caminho dos arquivos CSS por exemplo. Basta alterar aqui.

4 – Construindo seu Layout

Vamos agora construir o seu Layout.
Seria aquele topo e aquele rodapé que você não quer mexer. Ou um menu lateral.
Você pode construir o que quiser.

O local onde vamos criar nossos layouts foi definido na constante LAYOUTPATH.

Você pode ter quantos layouts quiser e nomeá-los como quiser.
Mas quando formos construir a classe você verá que definimos um Layout default para quando nenhum for chamado.
É esse que vamos criar agora. default.php

No exemplo abaixo eu criei um topo que tem um menu e um rodapé simples.

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html>
<head>

<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<title>{title_for_layout}</title>

{css_for_layout}
        	{js_for_layout}

</head>
<body>
<div id="geral">

<div id="topo">
<ul id="menu">
<li><a href="#">Link</a></li>
<li><a href="#">Link</a></li>
<li><a href="#">Link</a></li>
<li><a href="#">Link</a></li>
<li><a href="#">Link</a></li>
<li><a href="#">Link</a></li>
<li><a href="#">Link</a></li>
</ul>
</div>

<div id="meio">

{content_for_layout}

</div>

<br style="clear: both;" />

<div id="rodape">
<p class="rodape">
Todos os direitos reservados - Bla Bla Bla
</p>
</div>

</div>
</body>
</html>

É necessário prestar atenção em 4 variáveis que deixamos soltas no meio desse HTML do Layout.

• Primeira – {title_for_layout}
• Segunda – {css_for_layout}
• Terceira – {js_for_layout}
• Quarta – {content_for_layout}

Explicando rapidamente:
Essas Strings vão ser substituídas de acordo com o que definirmos no Controller em um próximo passo.

No lugar de {title_for_layout} irá o título da página. É legal podermos definir um título pelo controlador para deixá-lo dinâmico e assim ajudar no SEO.

No lugar de {css_for_layout} e {js_for_layout} entrarão os arquivos de CSS e JavaScript que definirmos para nossa página.
Você não precisa chamar todos os CSS ou JavaScripts se não for usá-los. Essa é uma grande sacada dessa solução.
Lembro de pegar projetos em Smarty onde estavão definidos inúmeros JavaScripts e CSS em um top.php onde em várias páginas eles nem era usados.

Por último, no lugar de {content_for_layout} irá o conteúdo da nossa View.
É o meio, o que muda.
É o que vamos fazer no próximo passo que está no próximo post.

Apesar de já ter trabalhado com CodeIgniter antes, nunca havia me envolvido tanto, entrado em suas configurações principais e etc. Me limitava ao superficial para fazer funcionar. Controler, consulta no banco pelo Model, chama a view para mostrar o conteúdo e fechou. No máximo chamar uma library.

Porém pediram para mim e meu amigo Ronie, que já tinhamos experiência com a ferramenta, para deixar ela configurada para múltiplos sites. Já tinhamos visto isso antes. Vamos lá! Pesquisar no segundo cérebro (Google)!

Um Wiki no site oficial propõe duas maneiras para se trabalhar com múltiplos sites em CodeIgniter. A primeira seria criando as pastas principais dos sites dentro de Application (Application é onde fica a estrutura do site). Funciona como se cada pasta dessa, fosse um application. Logo, você deve replicar o conteúdo da pasta application que vem por padrão no CodeIgniter para cada site que for ter, renomeando para um nome de acordo (No exemplo abaixo a pasta site1 e a pasta site2).

A segunda forma é bem similar. Você tiraria as pastas principais de dentro do Application, trazendo para a mesma raiz do system(system é onde fica o core do codeigniter).

Outro passo que a documentação pede, para as duas formas, é replicar o arquivo “index.php” (Nos exemplos acima representados por site1.php e site2.php), que vem por padrão na raiz do codeigniter, junto com a pasta system e a pasta application.
Deve se fazer essa réplica, para cada site/pasta principal, e editar a variável $application_folder, que devem conter o caminho para sua respectiva pasta principal. Nos exemplos do Wiki ele renomeia cada index para sua pasta do site, para ter como acessar cada site. que ficaria: http://www.seudominio.com/site1 ou http://www.seudominio.com/site2

Porém, precisavamos de outra coisa.
Foi pedido que separacemos a pasta dos arquivos css’s para fora da aplicação do CodeIgniter. Para que apenas o pessoal da programação tivesse acesso a isso. O pessoal do Layout (do CSS) não interferiria na Aplicação.

Depois de algumas idéias, rodando o tal arquivo “index.php” veio toda a solução. Simples !

Nesse arquivo é setado o endereço da pasta System, e, como já vimos antes, da pasta Application. Putz.. Ai fica tudo muito fácil.

Jogamos uma pasta system na raiz do servidor, e renomeamos para CI.

Para cada site, fizemos uma pasta principal (para onde o domínio é apontado). Dentro dessa pasta principal colocamos a Réplica do Application, com o nome de “app”, Uma pasta “www”, para os CSS’s e Imagens de Layout, e por último uma pasta “includes”, para Uploads do usuário como fotos de notícias, PDF’s e etc. Ficou como tento demonstrar abaixo:

Não queriamos deixar as cópias dos “index.php” soltas para fora de tudo, como o Wiki deixa a entender. Colocamos dentro de cada Pasta Principal. O que facilitou no sentido da URL, pois geralmente quando você entra em uma pasta pelo browser, ele procura por um “index” não é mesmo ? Então para acessar cada site, é só entrar na pasta principal. Ele pega o index.php, e faz todo o Trabalho Hard Mode.

Nossa URL então, ficou apenas com o dominio do site, que é apontado para pasta do site. Como cada pasta tem o index, fechou.

Na edição dos arquivos “index.php”, setamos a variável $system_folder da seguinte maneira:

$system_folder = "../CI";

Dois pontos para quem não sabe, volta um diretório. e CI, foi o nome que demos para nossa pasta system. Resumindo: Volta um e entra na pasta CI

Apontamos a variável $application_folder para nossa réplica da pasta Application, que é a pasta app no exemplo acima.

$application_folder = "app";

E isso resolve tudo. Ou seja, Podemos fazer a organização do nosso projeto para múltiplos sites como achar melhor. É só editar o cara que manda em tudo, que é o arquivo “index.php”, da maneira correta.

Confira um exemplo passo a passo, clicando aqui.

Em breve mais posts sobre CodeIgniter. Valeu !!!