Basicamente você pode usar Fragments quando o tempo de leitura do fragmento for menor do que o tempo de geração do mesmo contéudo. Isso pode ser muito útil naqueles casos onde você tem um menu ou parte do seu layout que pode ser processada uma única vez e sempre ser carregada de um cache em vez de ser processada a view a cada requisição.

Como usar

Vamos usar o exemplo do menu:

// Cache do fragmento por 10 minutos
if (!Fragment::load('viewMenu', Date::MINUTE * 10))
{
	// Tudo até a chamada Fragment::save() será gravado como fragmento
	echo html::anchor('inicio','Início');
	echo html::anchor('kohana','Kohana');
	echo html::anchor('plugins','Plugins');
	echo html::anchor('contato','Contato');

	// Salva o fragmento em cache
	Fragment::save();
}

O código já comentado fica bem mais fácil do que explicar :)
Simplificando, funciona da seguinte forma:

1. Fragment::load() tenta carregar o fragmento do cache
2. Se não encontrar retornará false, e ficará aguardando o trecho a ser guardado neste fragmento até a chamada Fragment::save()
3. O padrão de armazenamento de cada fragmento é 30 segundos, mas você pode especificar um timeout na chamada Fragment::load()
4. Você pode forçar um fragmento ser excluído usando Fragment::delete() ou usando timeout como zero

Sem inspiração pra uma imagem, postei o código de exemplo :)

Não é interessante usar Fragments para guardar variáveis, objetos ou ainda resultados de banco de dados. Para objetos mais complexos o módulo Cache é muito mais robusto e eficiente.

É simples, é Kohana!
É por isso que eu gosto :)

Salve no arquivo application/classes/request.php:

<?php defined('SYSPATH') or die('No direct script access.');
class Request extends Kohana_Request
{
	public function execute()
	{
		$this->action(str_replace('-', '', $this->action()));
		$this->controller(str_replace('-', '', $this->controller()));
		return parent::execute();
	}
}

A função str_replace elimina todas as ocorrências de hífens em controllers e actions da sua URL. Mas você pode adaptar e usar conforme precisar no seu projeto, substituindo por algum outro caractere, se essa for a necessidade.

Kohana: URL's com hífen

Assim, permite por exemplo você tem uma URL
http://seuprojeto.com/sobre-nos/localize-no-mapa
ser redirecionada para o controller sobreNos e a action localizeNoMapa

É simples, é Kohana!
É por isso que eu gosto :)

Foto Oficial da #phpSCconf 2010

Foi muito interessante ver o número de pessoas presentes que já tiveram contato ou conheciam o Kohana (tanto como o CodeIgniter). Surpreendeu minhas expectativas sobre quantas pessoas estão usando o Kohana para facilitar e agilizar o desenvolvimento web.

Confira os slides da palestra

Para instalar (e sair usando) o Kohana precisamos fazer poucas configurações, fornecendo muitas das ferramentas que um desenvolvedor precisa dentro de um sistema altamente flexível. Hoje vamos ver como é a instalação passo a passo do Kohana.

photo credit: Laughing Squid

Neste tutorial vou considerar que você já tem seu servidor Web instalado (Apache, IIS, lighthttd, etc) e seu PHP 5 devidamente configurado.

1. Download da versão estável no site do Kohana
2. Descompactar o seu download (isso criará uma subpasta chamada kohana)
3. Copiar o conteúdo da pasta kohana do procedimento anterior dentro do seu webroot (local onde o webserver acessa os arquivos na raiz)
4. Abrir o arquivo application/bootstrap.php e fazer pequenas alterações:
   • Configurar o timezone para a sua região (aqui uso America/Sao_Paulo)
   • Configurar o locale para o Português Brasil (aqui uso pt_BR.utf-8)
5. Definir premissões de gravação para:
   • application/cache
   • application/logs
6. Testar sua instalação abrindo o endereço do seu servidor web no seu browser, você verá a tela abaixo (clique para ampliar):
   
7. Remova renomeie o arquivo install.php e está tudo pronto!

O Kohana está instalado e pronto para uso no seu servidor de desenvolvimento.
Veja mais tutoriais sobre o Kohana para começar o desenvolvimento usando este framework.

Simples não? É Kohana!
E é por isso que eu gosto :)

Minha palestra será no sábado 28/Ago as 17:15h e o título é Desenvolvimento Ágil com Kohana Framework, confira toda a grade do evento.

Se você procura tutoriais sobre o Kohana, clique aqui

Os controllers comunicam-se diretamente com os models enviando e recebendo informações, muitas das informações recebidas são repassadas as views para serem renderizadas no navegador do usuário, e podem também ser recebidas das views dentro dos controllers para serem processadas pelos models novamente.

Enfim, deu pra perceber que o controller é quem controla o fluxo de informações e da aplicação :)
Trabalhar com Controllers no Kohana é muito fácil, vamos ver como:

Convenções para Controllers

• O arquivo deve ser gravado em application/controller
• O nome do arquivo deve ter o mesmo nome da classe, em minúsculo.
  Exemplo: artigos.php
• O nome da classe deve conferir com o nome do arquivo, iniciada de Controller_ e com a primeira letra em maiúsculas.
  Exemplo: Controller_Artigos
• A classe deve ser extendida do Controller base (ou de outro controller).
  Exemplo: Controller_Artigos extends Controllers
• Os métodos que serão acessíveis pela URL devem ser públicos e precedidos por _action.
  Exemplo: public function action_todos()
  

Acessando e Requisitando um Controller

Por padrão, o acesso a um controller é feito da seguinte forma:

http://dominio.com/index.php/<controller>/<action>

Então para acessarmos o controller artigos e a action todos, nosso exemplo ficaria assim:

http://dominio.com/index.php/artigos/todos

Criando um Controller

Seguindo nosso exemplo, vamos criar um controller artigos:

application/controller/artigos.php

class Controller_Artigos extends Controller
{
  public function action_index()
  {
    $this->request->response = "A resposta para a vida, o universo e tudo mais é 42!";
  }
}

Acessando http://dominio.com/index.php/artigos/index (ou dominio.com/artigos/ porque a action_index é a padrão, por default) teremos o seguinte resultado:

A resposta para a vida, o universo e tudo mais é 42!

Recebendo Parâmetros via URL

Como o controller é responsável pelo fluxo de informações dentro da aplicação, uma das grandes utilidades é receber informações. Uma das formas mais simples é via URL. Vamos aprimorar nosso exemplo, solicitando artigos pelo seu número:

class Controller_Artigos extends Controller
{
  public function action_index()
  {
    $this->request->response = 'A resposta para a vida, o universo e tudo mais é 42!';
  }

  public function action_ver($numero=0)
  {
    // Rotina para pesquisar artigos
    // {...}
    $this->request->response = "Você solicitou o artigo número $numero";
  }
}

No exemplo acima, acessando http://dominio.com/index.php/artigos/ver/12 teremos o seguinte retorno:

Você solicitou o artigo número 12

Funções Privadas em Controllers

Em determinadas situações precisamos manter algumas funções disponíveis como public mas não queremos que elas sejam acessadas pela URL, neste caso é só não usar o prefixo action_ no nome da function.

class Controller_Artigos extends Controller
{
  public function megasena()
  {
    $this->request->response = 'Os números da megasena são ...';
  }
}

E assim se tentarmos acessar http://dominio.com/index.php/artigos/megasena não teremos acesso a esta função dentro do controller, como esperado!

Conclusão

Nos próximos tutoriais do Kohana vamos trabalhar com Views, Models e depois a troca de informações entre eles.
Qualquer problema ou dúvida, fique a vontade nos comentários.

Simples, não? É Kohana!
E é por isso que eu gosto :)

photo credit: JohnSeb

O uso de Memcache normalmente segue um padrão:

1. O aplicativo recebe uma consulta do usuário ou do aplicativo.
2. O aplicativo verifica se os dados necessários para satisfazer a consulta estão no cache de memória.
3. Se os dados estiverem no cache de memória, o aplicativo utiliza os dados.
4. Se os dados não estiverem no cache de memória, o aplicativo consulta o armazenamento de dados e armazena os resultados no cache de memória para solicitações futuras.

Legal, e no Kohana?

Primeiro passo, vamos copiar o arquivo /system/config/cache.php para /application/config/cache.php
Configure o arquivo para que fique desta forma:

$config['default'] = array(
  'driver'   => 'memcache',
  'params'   => '',
  'lifetime' => 3600,
  'requests' => 1000
);

Você pode alterar os parâmetros como precisa, onde sugiro:

lifetime = 3600 segundos (1h de timeout)
requests = 1000 (mil requisições de timeout)

E se o MemCache estiver em outro servidor?

Ai está, uma dica importante! Se você não executa o MemCache no mesmo servidor do Kohana, você precisa alterar o arquivo cache_memcache.php  em application/config. Se você tiver mais de um servidor memcached, você pode adicioná-las ao array $config['servers']. Veja um exemplo:

$config['servers'] = array(
  array(
    'host' => '127.0.0.1',
    'port' => 1234,
    'persistent' => FALSE
  )
);

Exemplos

Pronto as configurações, agora é a hora tão esperada em usar o cache, e realmente é a etapa mais fácil:

// Instancia o cache
$cache = Cache::instance();

// Tentando obter dados do cache
$retorno = $cache->get('item');

if(!$retorno)
{
  // Dados não retornaram, obtendo dados da origem
  $retorno = ORM::Factory('teste')->dados();

  // Gravando novo cache
  $cache->set('item',$retorno);
}

Simples, não? É Kohana e é por isso que eu gosto!

Kohana é um framework PHP 5 que utiliza orientada a objeto (OOP) e o modelo de arquitetura MVC (Model View Controller).

Ele é um framework que é baseado no CodeIgniter e quando algumas coisas não iam bem na evolução do CodeIgniter e a comunidade achou que poderia contribuir de forma efetiva no andamento do projeto de forma livre, foi criado o Kohana. No começo ele era chamado de Blue Flame, e por infringir algumas patentes, posteriormente seu nome foi alterado para Kohana.

Bom, chega de papo e vamos ao que interessa.
O que o Kohana tem de melhor?

Liberdade no desenvolvimento

O Kohana é projetado e mantido pela comunidade e não por uma empresa como é o CodeIgniter. O desenvolvimento do Kohana é dirigido por um time de pessoas dedicadas que necessitam de um framework para solucões rápidas e poderosas.

Praticidade
Nada de precisar ficar configurando bootstraps mirabolosos ou fazendo mil configurações em arquivos XML/YAML/whatever.
Instale, configure pouca coisa e vá trabalhar. O trabalho sujo já foi feito pra você, use o que ele tem de melhor

Strict PHP 5 OOP
PHP4 já era! PHP5 com orientação a objetos oferecem muitos benefícios e maior segurança: visibility protection, carregamento automático de classes, sobrecarregamento, interfaces, classes abstratas e singletons.

Extremamente leve
Kohana não possui dependências de extensões PECL ou bibliotecas da PEAR. Bibliotecas gigantescas e monolíticas são evitadas a favor de otimizar as solucões desenvolvidas.

GET, POST, COOKIE e SESSION funcionam como esperado
Kohana não limita seu acesso aos dados globais, mas oferece filtros e protecão contra XSS (Cross Site Scripting). Ele oferece formas seguras e limpas de acessar estes dados, sem precisar ficar ficar dando voltas no palheiro.

Carregamento automático de classes
Estas são carregadas sob demanda, de acordo com a necessidade da sua aplicação. Sem precisar ficar dando loading em bootstraps, sem precisar ficar declarando em controllers quais classes do framework vá utilizar.

Não existem conflitos de namespace
Todas as classes estão adequadas para permitir componentes com nomes similares, a favor de uma API mais coerente.

Recursos em Cascata / Extensibilidade
Quase todo o Kohana pode ser sobrecarregado por métodos que você mesmo pode escrever sem precisar editar os arquivos do core do framework. Além de permitir qualquer customização, resulta em atualizaçãoes mais seguras e organização de forma transparente no desenvolvimento.

Biblioteca baseada em “Drivers” e API consistente
Bibliotecas podem ter diferentes “drivers” para manipular diferentes APIs transparentemente. Por exemplo, múltiplas opcões de armazenamento dos dados de sessão estão disponíveis (banco de dados, cookie e nativo), visto que a interface é uniforme. Isso permite que novos “drivers” sejam desenvolvidos para bibliotecas de terceiros já existentes, mantendo a API consistente e transparente.

Manipulacão de Eventos
Handlers de Eventos baseados no padrão Observador permitem uma maior customizacão.

Módulos Extras
Com todas as características acima, vários módulos foram escritos por entusiastas e pela comunidade. Hoje o Kohana permite integrações com várias bibliotecas, incluindo qualquer biblioteca do Zend Framework. É o que eu sempre falo: Kohana + Zend Framework = Killer Combo

Simplesmente faça o upload
Kohana não tem necessidade de mil configurações a parte no seu provedor, e executa muito bem em qualquer provedor de hospedagem de respeito que tenha PHP 5, sem paranóias. Desenvolva e faça o upload!

Rápido ciclo de desenvolvimento
Resultados de desenvolvimento rápido em uma resposta mais rápida aos erros do usuário e alterações no software.

Curva de aprendizado pequena
O tempo para aprender a utilizar framework é bem menor do que em relação a outras frameworks. Realmente, isto é incomparável!

E agora?

Se você gostou do que leu, convido a baixar o Kohana e brincar um pouco com ele.
Em poucas horas estará usando ele no seu próximo projeto!
http://kohanaframework.org

Gostou? Quer aprender como instalar e configurar?
Veja mais artigos sobre o Kohana

Simples não? É Kohana!
E é por isso que eu gosto!

Porém, quando vamos trabalhar com databases que não seguem estas convenções (o que pra mim é algo muito comum) ou que já atendem a outros sistemas tambéme e não podem ser modificadas, temos de configurar somente as excessões para que tudo continue funcionando perfeitamente.

Algumas destas convenções, e suas excessões:

Nomes de tabelas no plural

Nomes de tabelas devem estar no plural. Por padrão o ORM obtém o nome da tabela e determina seu plural com ajuda do helper inflector.
Convenção: Ex: users, invoices.
Excessão: Declarar a propriedade table_name

protected $table_name = 'usuarios';

Models no singular

Enquanto pela convenção as tabelas no banco devem ter seu nome no plural, o nome do arquivo e do model deve ser no singular.
Convenção: NomedaTabela seguido de _Model

class User_Model extends ORM {}

Autoincrement

Toda tabela deve ter um campo autoincrement + primary key chamado id
Excessão: No model, declarar a propriedade primary_key

protected $primary_key = 'meucampoid';

Foreign Keys

Chaves estrangeiras devem ser nomeadas no banco de dados como nomeDoModel seguido de _id
Exemplo: invoice_id, user_id
Excessão: No exemplo abaixo, a tabela invoices esteja relacionada a users, porém na tabela invoices a chave estrangeira chame-se user_fk (que não segue o padrão sugerido)

Relacionamento entre Users e Invoices

No model Invoice_Model, declare a propriedade foreign_key

class Invoice_Model extends ORM {
    protected $foreign_key = array('user' => 'user_fk');
}

Tabelas Pivôs

Tabelas pivôs devem ser nomeadas pelos nomes das tabelas pais na ordem alfabética (legal e organizado não?), nesta forma tabela1_tabela2. Vamos usar como exemplo o relacionamento de muitos-para-muitos entre a tabela users e as tabelas de functions, tabela de junção deve ser nomeada no banco como functions_users

Simples, não? É Kohana!
E é por isso que eu gosto.

Para quem tem pressa, a resposta está ai: a migração de aplicações Kohana 2.x para 3.0 não será automática e exigirá revisão em alguns pontos do desenvolvimento, a começar que partimos de MVC para HMVC

Que raios é HMVC?

Não complique!
HMVC (Hierarchical Model View Controller) é um padrão de design novo, porém muito semelhante ao MVC que você já conhece, adicionado de uma hierarquia no design original do MVC. Quando uma requisição URI for solicitada, qualquer parte do MVC pode chamar outro item da hierarquia, o que permite o desenvolvedor uma maior flexibilidade e modularização do sistema que estiver utilizando. A vantagem é que se você quiser continuar com o padrão MVC, nada vai impedir você trabalhar desta forma.

Bootstrap

Quem me conhece sabe que eu odeio não gosto muito bootstrap do Zend Framework. O ZF é uma plataforma invejável tanto pela sua estabilidade como pelas suas características, porém montar arquivos de bootstrap decentes no ZF nunca foi sucesso pra mim. Sei lá, acho que fiquei mal acostumado com o Kohana onde eu ligo o carro e saido acelerando, e no ZF eu tinha que toda vez parafusar as 4 rodas e calibrar todos os pneus antes de sair rodando a aplicação :)

Voltando ao assunto, KO3 terá um bootstrap dedicado, porém você não vai precisar sair montando um do zero e sofrer horas para deixar ele funcionando: um bootstrap padrão que atende praticamente todas as aplicações já fará parte do pacote, somente o tunning da aplicação ficará por sua conta, como você já fazia no Kohana 2.x

Arquivos de Configurações

Boa parte dos arquivos do diretório application/config e suas diretivas também foram movidas para o arquivo de bootstrap. Quem já teve contato com Zend Framework estará bem familiarizado com esta mudança.

Controllers viraram Classes

Os controllers que estavam em /application/controllers vão para /application/classes/controllers.
Libraries e Helpers seguem o mesmo padrão e são todos classes agora, tudo fica mais organizado e OO.

Estrutura de diretórios e autoloading do KO3 também mudou: Uma nova convenção de arquivos foi desenvolvida de forma que simplifica a identificação e localização de classes. Todas as classes fazem uso do sublinhado (_). A estrutura de nomes é separada, como anteriormente, mas você vai notar uma diferença no formato.

Teste_Controller agora será Controller_Teste (/application/classes/controller/teste.php)
Kohana_Session_Cookie corresponde a /system/kohana/session/cookie.php

Ainda quero fazer alguns testes com o novo driver ORM, porém não me sobrou tempo ainda!
Acho que com o lançamento oficial da nova versão (que hoje está em RC3) posso publicar uma análise mais voltada ao ORM, que será exclusivamente baseado no PDO