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.

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!!!

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.

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.
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 como nome do seu hook.

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.

Ontem precisei comparar os resultados de dois arrays e deles trazer os valores que estavam em apenas um dos arrays.

A princípio procurei uma função que fizesse isso pra mim, achei que o array_diff fizesse isso para a gente. Mas me enganei! Não achei uma função com esse resultado.

A função array_diff na verdade traz apenas os valores que constam no primeiro array, mas não constam no segundo.
Exemplo:

<?php

$array1 = array("bola", "quadrado", "triangulo");
$array2 = array("esfera", "quadrado", "triangulo");

$result = array_diff($array1, $array2);
print_r($result);

?>

O resultado do código acima nos retorna um array com o valor “bola”.
Pois é o único valor que consta no primeiro array e não no segundo.

O que eu precisava é que ele me retornasse também os valores que tinham no segundo array e que não constavam no primeiro.

Resolvi da seguinte forma:

<?php

$array1 = array("bola", "quadrado", "triangulo");
$array2 = array("esfera", "quadrado", "triangulo");

$result1 = array_diff($array1, $array2);
$result2 = array_diff($array2, $array1);

$full = array_merge($result1, $result2);

print_r($full);

?>

Primeiro fazemos retornar os valores que estão no primeiro array e não no segundo ($result1).
Em seguida os que estão no segundo array e não no primeiro ($result2).
Após isso unimos os dois arrays através da função array_merge.

E o resultado retornado é [0] => bola [1] => esfera, como esperado.
Bola que está apenas no primeiro array, e esfera que está apenas no segundo.
Os demais valores aparecem em ambos os arrays, logo, ficam de fora.

Adicionem outros elementos aos arrays para testar e confiram os resultados.

Grande Abraço.

Você compra o domínio principal, www.site.com.br. E você vai ter duas versões desse site, uma para cada cliente, que vai usar todas as regras de negócio iguais. A única diferença será o layout. Os clientes pediram os subdomínios branco.site.com.br e preto.site.com.br.

Você pode fazer duas cópias do site em pastas diferentes, mas levando em consideração que eles tem o mesmo CORE, isso não é muito inteligente. Pense se você tiver que fazer uma atualização, você vai ter de mexer em ambos os projetos.

Porque não fazer os subdomínios como links simbólicos para uma mesma pasta? De lá você pode fazer uma verificação. Se for um site, pega o layout branco, se for o outro pega o layout preto.

Problema:

No Codeigniter você define a URL principal do seu projeto nos arquivos de configuração, na variável $config['base_url']. Você não vai ter como colocar os subdomínios lá. O que fazer?

Solução:
Usar a Global $_SERVER.

Essa Global traz informações como o host que você está acessando, o email do administrador da máquina, o software usado, a configuração do TimeOut entre outras.

Para que você mesmo visualize tudo isso faça o seguinte. Abra o seu config.php do CodeIgniter e logo acima de onde está setado a variável $config['base_url'] de um print_r, como abaixo:

|--------------------------------------------------------------------------
| Base Site URL
|--------------------------------------------------------------------------
|
| URL to your CodeIgniter root. Typically this will be your base URL,
| WITH a trailing slash:
|
|       http://example.com/
|
*
print_r($_SERVER);
die;
$config['base_url']     = "http://www.site.com.br/";

Veja em seu browser todas as opções que você tem nessa global.

Dê uma atenção na primeira opção que vêm no array, o HTTP_HOST. Ele traz o endereço primário que você está acessando. É o que você precisa para setar seu config de acordo com a url que seu visitante acessar.

Dando um print apenas nesse cara,

|--------------------------------------------------------------------------
| Base Site URL
|--------------------------------------------------------------------------
|
| URL to your CodeIgniter root. Typically this will be your base URL,
| WITH a trailing slash:
|
|       http://example.com/
|
*
print_r($_SERVER['HTTP_HOST']);
die;
$config['base_url']     = "http://www.site.com.br/";

ele retorna o seu subdomínio.

Agora é só fazer uma adaptação.

|--------------------------------------------------------------------------
| Base Site URL
|--------------------------------------------------------------------------
|
| URL to your CodeIgniter root. Typically this will be your base URL,
| WITH a trailing slash:
|
|       http://example.com/
|
*

$config['base_url']     = "http://" . $_SERVER['HTTP_HOST'];

Seja lá qual subdomínio você acessar, ele vai setar como base_url para você.

Caso você não use subdomínios, esse artifício pode ser usado para você deixar o base_url automatizado para seus projetos.

Espero que tenham curtido a idéia.
Qualquer dúvida só mandar.
Abraços!!

Vocês sabem, muitos projetos em sistemas são similares, sempre aquela mesma coisa…Listar, Inserir, Editar e Remover.
Isso me levou a querer criar algo para facilitar tudo isso.

Vendo meu Amigo Fábio Tomio mandando ver no Ruby On Rails, ele me mostrou que criava um cadastro (Listar, Inserir, Editar e Remover) muito facilmente, com apenas um comando no terminal, usando a funcão Scaffold se não me engano.

Inspirado nisso, resolvi fazer um Shell Script que geraria todas as views, controller e model prontas com essas opções.

Introdução

• Chamei de CiForms.
• Essa é uma versão de teste. É a versão Zero.
• Fiz esse script como estudo. Não tenho pretensões de lucros, suporte, nem nada com ele.

Porque não usar o Scaffolding do CodeIgniter

• O Scaffolding do CodeIgniter não é aproveitável para o desenvolvimento de um projeto, ele não segue o padrão MVC do Framework. Como consta no manual, ele é apenas uma maneira de popular rapidamente uma tabela.

Limitações dessa versão

• É um shell Script. Vai rodar apenas em base Unix. Fiz testes no Linux distribuição Ubuntu 8.10 e no Leopard MAC OSX 10.5.6. Não vai rodar no Windows.
• Por enquanto está rodando apenas em DataBase MySQL, Tive problemas com a função listFields com outros bancos.
• Você deve estar com o módulo Rewrite do apache instalado, e usando o .htaccess como indicado no manual do CodeIgniter para fazer suas URL amigáveis, senão a navegação vai ficar super esquisita.
• Você deverá chamar o script de dentro da sua pasta Application e as pastas Controllers, Models e Views não podem ter sido renomeadas.

Como Usar

• É bem simples. Basta chamar o script, passando o nome da tabela e em seguida o de sua PK.
• O script tem uma opção para ajuda (-h ou –help) e para verificar a versão (-V ou –version)

Exemplo prático

Baixe o Sheel Script clicando aqui.

É necessário colocar o sheel dentro da pasta applications.

Em seguida Vamos executá-lo no terminal.
Para chamar o script, apontamos o caminho atual (./) e depois seu nome (ciforms.sh).
Repare que se não passar os parâmetros corretos ele não irá executar e irá lhe oferecer o help.

Colocando corretamente os parâmetros (Nome da tabela e em seguida a Primary Key da tabela)

O Script é executado e você já pode conferir nas pastas que foram criados os arquivos .php.
Um controller, um model, e três views.

Basta agora chamar no browser o seu site, em seguida o nome da tabela.
Aqui está a listagem, onde você tem o Id do registro e os opções para Editar ou Remover.

Após Editar você volta para a listagem.

Após clicar em remover, você repara na listagem com um registro a menos.

Fique a vontade para abrir o código e conferir como são feitas as chamadas e tudo mais. O Shell vai gerar tudo em uma linha só. Se você usa o Eclipse ou o Aptana como editor basta dar um Ctrl+Shift+F para identar tudo automaticamente.

Os Arquivos php não contam com praticamente nenhum comentário, pois tive problemas do Shell em relação a eles.

Devo mexer em breve nele para funcionar com Postgres. Até lá, um abraço a todos.

Estava recebendo muitas dúvidas, vamos ver se com este exemplo consigo deixar as coisas mais claras para todos.

Começando do zero.

Baixei a última versão do CodeIgniter.
Descompacto ela no meu desktop.

Dentro dessa pasta veio o system, o user_guide, o index.php e o license.txt.
Costumo deletar o User_guide, pois uso a documentação online.

Atenção agora !
Dentro da pasta system temos a pasta application. É esta pasta que faz o seu site funcionar. Com esta informação em mente vamos em frente.

Para começar a trabalhar com o servidor. Começe criando uma pasta para cada site. Como exemplo site1 e site2.




O que o site vai precisar para funcionar ? Sim, como vimos acima é a pasta application. Dentro da pasta de cada site vamos precisar de uma application.



A pasta application, claro, deve ir com a estrutura que vem por padrão nela, como você deve ter reparado na imagem acima.

Agora que já temos o local dos sites prontos, precisamos do que faz o Codeigniter funcionar, que é todo o restante da pasta system. Essa pasta deve estar no mesmo nível dos seus sites.



Ok. Quase lá.
Agora, sabe aquele index.php que veio quando descompactamos o codeIgniter ? Como digo no outro post, é ele quem indica o caminho da pasta application do seu site, e também do core do codeIgniter. Logo, vamos precisar de um deles para cada site.



Agora precisamos editar esse arquivo index.php. Vamos começar pelo do site1.
Procure pela linha

$system_folder = "system"

Esta variável indica aonde está o core do seu sistema, a pasta system.
No nosso caso ela está um nível acima, então basta mudar para

$system_folder = "../system"

Logo na sequência você deve ver a linha

$application_folder = "application"

Essa é a variável que indica onde está a pasta application desse site (lembrando…estamos alterando o site1). O caminho está correto, então, mantemos assim.

Faça o mesmo para o site2, indicando onde está o core do codeIgniter(pasta system) e a pasta application.

Está feito!

Agora, apenas para ficar mais explícito, vamos alterar a view de cada site.
Dentro de Application > views, temos o arquivo welcome_message.php.



Dentro desse arquivo, vem a mensagem padrão de boas vindas do codeIgniter. Na do site1 tirei tudo que havia (ctrl + a  – del) e coloquei apenas o título

<h1>::: SITE 1 :::</h1>

e na do site2 apenas o título

<h1>::: SITE 2 :::</h1>

Agora basta acessar as pastas para conferir o resultado.

Para detalhes mais técnicos desse step by step, confira o antigo post.

Ainda com dúvida ? Faça aqui o download dos arquivos.

Caso ainda tenha sobrado dúvidas…entre em contato.
Abraços !!!

Sexta pela manhã, foi minha primeira tarefa do dia. Achei que seria algo bobo. Realmente era, mas levei 4 horas para descobrir.

Comecei pelos arquivos de JavaScript vendo se estava tudo ok.
Os retornos via ajax do banco estavam ok.
Parti para os controllers que gravam a sessão no browser.
Comentei a biblioteca que faz verificação da sessão para deixar eu acessar livremente a aplicação. Dei um print no valor da sessão, que pelo codeIgniter se verifica assim:

//Não esqueça de chamar o helper session
// Login é o valor que eu estava gravando na sessão
print($this->session->userdata('login'));

// A tradicional global session não funcionará no codeIgniter
print($_SESSION['login']);

No Firefox tudo ok. No Internet Explorer em branco. Que beleza, o Internet Explorer não está deixando escrever na sessão…

Navegando pelo segundo cérebro não tive nenhuma resposta conclusiva. As soluções propostas não se encaixavam para mim. Atualizar versão do apache, tirar Underlines da url, tirar números do nome do servidor, nada disso fez sentido pra mim.

Sem idéias, me juntei ao meu amigo Ronie e ao Rafael que também faz parte da minha equipe nesse projeto para caçar uma solução.

Tiramos o redirecionamento do Login, para manter na mesma página. E demos ali também um print, dessa vez em todos os valores da sessão

//Print_r por se tratar de array
print_r($this->session->userdata);

Os valores estavam ali, o problema estava no redirecionamento então.

Quebramos a cabeça demais, e como antes estava funcionando no IE, resolvemos rever tudo de brusco que mudamos no sistema.
Verificamos rotas, Jquery e seus plugins, Verificações de nível de acesso, nada.
Até que me lembrei que havia mudado a configuração da sessão, para expirar em meia hora (1800 segundos) tirando do padrão de duas horas (7200 segundos) que vem no CodeIgniter. Esses valores são alterados no config.php, ali você dá de encontro com outras configurações para sua sessão, como nome dela e etc.

E, Sim, era isso. Voltamos ao default do codeIgniter e tudo voltou a funcionar. Me lembro de ter tido uns problemas similares trabalhando com PHP sem frameworks, mas nem suspeitava. Fomos testando para ver o mínimo que o IE iria aceitar de tempo de expiração. Chegamos no valor de 3835 segundos. Mesmo assim continuou muita instável, e setamos em 4000 segundos.

Problema resolvido após 4 horas de Prints, Alerts, Pesquisa, Palpites e Indignação…

Valeu..
Abraços !!!

Ocorrência: “Sempre demorou para carregar. Funcionava normal. Mas agora quando um cliente tem muitos produtos, não abre. Dá erro 500.”
“No servidor de testes está funcionando, no do ar não. ”

Pesquisa: Fui atrás do tal erro 500. Claro já havia o visto antes, mas não sou daqueles que sabe de cor o significado dos erros de servidor e do apache, e nem dos bips de erro da placa mãe. No segundo cérebro há muitas inconstantes sobre o erro 500. Uns dizem ser erro de permissão, outros de configuração. Felizmente meu Delicious me salvou. Eu tinha salvo esse link com uma lista sobre os erros de servidor há algum tempo.

Agora sim. Erro 500: Algo não foi compreendido pelo servidor.
Certo. Muito bom. Não ajudou muito. Em nada melhor dizendo.
E agora?

Eu e a programadora responsável pelo job, dando uma andada pelo sistema, nos deparamos com uma Consulta SQL cavalar, com várias linhas, Joins e com funções recursivas.

Primeiro chute: Inspirado pelo nosso supervisor de desenvolvimento, vamos ver o Timeout do apache. Vamos comparar o timeout dos dois servidores. Como fazer isso ?
No arquivo de configuração do apache (http.conf no Apache ou apache2.conf no Apache2) você deve encontrar uma linha com o seguinte comentário e em seguida a declaração da variável como abaixo.

#
# Timeout: The number of seconds before receives and sends time out.
#
    Timeout 300

300 é o default da configuração. E é assim que estava setado nas duas máquinas. Não foi dessa vez.

Segundos passos: Eu e a Analista de sistemas já estavamos nos preparando para fazer backups dos arquivos do ar e subir os do servidor de teste. Afinal, estava funcionando local, não adiantava ficar rodando o código e dando print() e print_r() pra tudo quanto é lado. O que você faria ?

Mas foi quando um dos técnicos da TI ganhou a tarde. Mudou o max_execution_time no arquivo de configuração do PHP, o php.ini.
O que é isso ? O nome diz tudo não ? É o máximo de tempo que o PHP vai tentar ficar executando um script.
Onde arrumo isso ? No php.ini, você vai encontrar as variáveis de Limites de recurso, como abaixo.
;;;;;;;;;;;;;;;;;;;
; Resource Limits ;
;;;;;;;;;;;;;;;;;;;

max_execution_time = 30 ; Maximum execution time of each script, in seconds
max_input_time = 60 ; Maximum amount of time each script may spend parsing request data
;max_input_nesting_level = 64 ; Maximum input variable nesting level
memory_limit = 16M ; Maximum amount of memory a script may consume (16MB)

Repare, aqui na minha configuração está com 30. Esse é o padrão. O Parceiro da TI setou para 60.

Testando: Olha só, o Cliente que tem mais de 100 produtos agora consegue entrar na sua lista. Apesar da demora. Xiiii…. mas o cliente com 500 produtos não.

Solução: Sim, é isso mesmo. Vamos aumentar mais ainda o max_execution_time.
Qual o máximo que podemos setar ? Segundo dizem, os monges shaolins já ficaram esperando por 8 horas a execução de um script PHP, para exercitar a paciência. Talvez não tenha limite, você pode testar e me dizer.
Resolveu ? Resolveu! Setamos para 300. Apesar da absurda demora (O loading do IE7 se manteve firme por aproximadamente uns 3 a 4 minutos), apareceu a lista de itens do cliente. O cliente não reclama mais que não aparece, apenas da demora.

Próximos passos: Estudar uma melhor performace para essa SQL. Ela parece ser a grande vilã de tudo. Conseguimos uma solução imediata. Nunca e jamais ideal.
Como conseguir essa melhor performance ? Particularmente não sei. Refazer a consulta sem tantos JOINS ou quebrar em partes podem ser algumas alternativas.

Fica aqui o meu relato de algumas horas de trabalho. Quem sabe surge esse problema por ai né?
Abraços.

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 !!!