Porém, como todos os outros artefatos que estão por aí, pode complicar ainda mais a vida de um programador, caso não seja usado adequadamente.

Introdução

Como visto no post anterior, onde está descrito algumas vantagens e desvantages de se usar o mod_rewrite, neste post vamos concluir o assunto. Assumindo que você esteja usando Apache com o mod_rewrite habilitado. Também é necessário o uso de arquivos .htaccess: Arquivos ocultos que contém diretivas interpretadas pelo Apache. Para que seu .htaccess funcione, deve se certificar de que a diretiva AllowOverride All esteja nos arquivos de configuração do apache. Ela deve ficar dentro de <Directory />, mais ou menos assim:

	AllowOverride All

Basta adicionar ao seus arquivos de configuração do apache ou requisitar seu servidor que o faça.

Conhecendo as diretivas

Antes de mais nada, vamos entender o que o mod_rewrite faz e é capaz de fazer, conhecendo seus parâmetros de configurações.

RewriteEngine on|off

Habilita(on) ou desabilita(off) o uso do módulo mod_rewrite.

RewriteOptions [inherit] [MaxRedirects=X]

Adiciona uma ou as duas opções.

inherit

Herda os parâmetros dos diretórios pai.

MaxRedirects=X

Ao invés de permitir o ‘loop infinito’ de redirecionamento, limita para X vezes. Caso, X seja alcançado, é disparado erro 500 (Internal Error).

RewriteLog /caminho/para/arquivo.log

Escreve o log dos eventos ocorridos no arquivo especificado.

RewriteLogLevel Level

Level inicia em 0 (desabilitado) e vai até 9 (números superiores podem ser utilizados, mas terão o mesmo efeito: irão logar quase tudo! Use somente para debug, pois vai diminuir a performance do apache. Bom para testes/debug, não para produção.)

RewriteBase /dir

Especifica /dir como a base para a procura do arquivo pelo Apache. (Mais explicações adiante)

RewriteCond

Responsável pela condições (a.k.a. IF’s). Pode-se utilizar inúmeros testes antes de especificar uma regra, sendo que a mesma só será executada ao passar por todos os testes com sucesso. Exemplos:

# Se o host for 123.45.67.89
RewriteCond %{REMOTE_ADDR} ^123.45.67.89$ [OR]
# ou for 98.76.54.32
RewriteCond %{REMOTE_ADDR} ^98.76.54.32
# A regra será a seguinte...

Podem ser usadas uma série de variáveis, entre elas:

• %{HTTP_USER_AGENT}
• %{HTTP_REFERER}
• %{REMOTE_ADDR}
• %{SCRIPT_FILENAME}
• %{QUERY_STRING}
• %{HTTP_HOST}
• mais informações aqui

RewriteRule

É aqui que realmente acontece a reestruturação da URL. Aqui é onde é dito o que deve ser entrepretado como o quê. Se o Padrão casar, o apache interpreta como se fosse o Caminho.

Por exemplo:

RewriteRule ^/(about|aboutme|sobre|sobremim|eu|minhavida)$ eu.html [L,NC]

Referências interessantes:

• Documentação do Apache
• ModRewrite CheatSheet

Exemplos de uso

Agora, com alguma noção sobre o mod_rewrite, vamos utilizá-los. Com alguns exemplos do que é possível. A idéia é que você descubra um jeito próprio e que funcione PARA VOCÊ. Esta é o tipo da coisa que não adianta fazer porque alguém disse que funciona, deve seguir os seus padrões e cobrir suas necessidades.

Exemplo 1: Organizando seu site no .htaccess

Convenhamos: uma notícia sobre um acidente não irá mudar. Depois de submetida para um site de notícias, dificilmente ela irá ser modificada. Ao menos que tenha passado desapercebido um erro de português ou uma estatística imprecisa, uma notícia não será modificada. Portando, é possível manter um cache da notícia em um arquivo .html, evitando consultas desnecessárias a bancos de dados ou outras fontes. Mas só porque ela está em cache, não significa que ela deva aparecer com o .html no fim ou .htm ou seja lá o que for.

RewriteEngine On
RewriteBase /
# Se não foi requerido um arquivo vazio (-s)
RewriteCond %{REQUEST_FILENAME} !-s [OR]
# Se não foi requerido um link simbólico (-l)
RewriteCond %{REQUEST_FILENAME} !-l [OR]
# ou um arquivo (-f)
RewriteCond %{REQUEST_FILENAME} !-f [OR]
# ou um diretório (-d)
RewriteCond %{REQUEST_FILENAME} !-d
# Aplique a seguinte regra:
# Se for notícia cacheada, chama o cache
RewriteRule ^ler/([A-Za-z0-9_-]+)$ /noticias/cache/$1.html [L]
# Se for para buscar por noticias
RewriteRule ^buscar/([A-Za-z0-9_-]+) /noticias/busca.php?termo=$1&area=noticias [L]
# Feeds
RewriteRule ^feeds$ feeds.php?area=noticias
# Feeds para a categoria X
RewriteRule ^feeds/(.*)$ feeds.php?area=noticias&categoria=$1

e assim por diante. Podemos estabelecer regras, inclusive, para subdomínios.

RewriteCond %{HTTP_HOST} ^en\.example\.com$
RewriteRule ^(.*)$ /news/english/index.php?q=$1 [L]
 
RewriteCond %{HTTP_HOST} ^br\.example\.com$
RewriteRule ^(.*)$ /news/brazilian/index.php?q=$1 [L]

uma outra sugestão:

RewriteCond %{HTTP_HOST} ^en\.example\.com$
RewriteRule ^(.*)$ /news/index.php?lang=en&q=$1 [L]
 
RewriteCond %{HTTP_HOST} ^br\.example\.com$
RewriteRule ^(.*)$ /news/index.php?lang=pt-br&q=$1 [L]

Exemplo 2: Listas de traduções

A questão de usar uma única variável que receberá o valor da url, funciona melhor para este segundo caso:

RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-f [OR]
RewriteCond %{REQUEST_FILENAME} !-s [OR]
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)$ index.php/$1 [L,NC]

Imagine que seu cliente queira criar páginas novas, de ‘política de privacidade’, ’sobre a empresa’, seja lá qual for o assunto da página. Ele vai querer acessá-la de forma rápida e acessível. Para tanto, index.php?area=view_page&page=4354 não parece agradar muita gente. Não seria interessante deixar que o próprio cliente crie seu padrão de URL? Talvez /politicas ou /empresa.

Existe uma forma interessante de se fazer isso: usando uma lista de expressões regulares e seus arquivos originais, os quais serão usados caso as expressões regulares casarem. Por exemplo, nos casos acima, apenas com o código abaixo no .htaccess, já poderíamos fazer algo:

A idéia é usar a REQUEST_URI (no php $_SERVER['REQUEST_URI']). Ela retornará, por exemplo, /ler/minha_noticia_bombastica que casará com ^/ler/([a-z0-9_-])$ e por consequência, irá chamar a noticias.php. Agora, como pegar o ‘minha_noticia_bombastica’ ? Fácil! Basta apenas utilizarmos os grupos das expressões regulares de forma apropriada. Usando o exemplo do php, com preg_match podemos resolver isso!

$urlPatterns = Array(
	'/^ler\/([a-z0-9_-]+)$/i' => 'noticias.php'
);
foreach ($urlPatterns as $pattern => $fileName)
	if (preg_match($pattern, $_SERVER['REQUEST_URI'], $vars)) {
		$_GET = $vars;
		include $fileName;
		break;
	}
}

Pronto! Alguns usuários podem ter notado, mas $vars irá ser uma sequência numérica dos grupos casados:

0 => /ler/minha_noticia_bombastica, 1 => ‘minha_noticia_bombastica’

Para resolver isso, podemos dar nomes aos grupos, o que seria extremamente normal para o programador (que utilizaria a variável $_GET normalmente) e bonito aos olhos do cliente. Para tanto, modificamos a nossa $urlPatterns:

	$urlPatterns = Array(
		'/ler\/(?<news -slug>[a-z0-9_-]+)$/i' => 'noticias.php'
	);</news>

Assim, poderemos acessar $_GET['news-slug']. Como fica mais difícil do usuário modificar nomes de variáveis vindos da URL, se torna uma solução segura. Podemos ter certeza de que $_GET['news-slug'] não conterá aspas, caracateres hexadecimais ou qualquer outro tipo de código malicioso. Pois se tivesse, não passaria no teste da expressão regular. E também nos certificamos de que aquele arquivo (noticias.php) só esteja sendo acessado, caso nossa index.php o esteja incluindo. Porque o usuário não conseguirá acessar de fora.

Neste caso, nós estipulamos os valores na $urlPatterns, mas ainda se pode pegar esses valores do banco de dados, por exemplo. Uma lista de ‘tradução’ para a url. Funciona muito bem, principalmente com páginas estáticas ou fixas. Ao invés do cidadão digitar index.php?area=pages&page_id=4232, ele estará acessando /sobre-a-empresa. Para usuários provenientes de sites de busca, isto é muito importante. Lhe dá muito mais segurança e você garante o seu clique. Ele vai direto ao ponto.

Decorator Pattern

É um pattern desenvolvido para modificar um determinado objeto (seja modificar alguma coisa já existente ou delegar uma nova responsabilidade) sem a necessidade de extendê-lo. O que é muito bom, assim, o reaproveitamento de código é maior ainda! Enfim, vou tentar dar uma explicada no pattern:

Diagrama de Classes do Decorator Pattern

Abaixo segue o código usado:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91

class Message {
 
	protected $msg;
 
	public function __construct($msg) {
		$this->setMsg($msg);
	}
 
	public function getMsg() {
		return $this->msg;
	}
 
	public function setMsg($msg) {
		$this->msg = $msg;
	}
 
	public function __toString() {
		return $this->getMsg();
	}
 
}
 
class Success_Message extends Message {
	public function __construct($msg) {
		parent::__construct($msg);
		$msg = new DivClass_Decorator(
			new Li_Decorator(
				$this
			)
			,'success-msg');
		$this->setMsg((String)$msg);
	}
}
 
class Error_Message extends Message {
 
	public function __construct($msg) {
		parent::__construct($msg);
		$newmsg = new DivClass_Decorator(
			new Li_Decorator(
				$this
			)
			,'error-msg');
		$this->setMsg((String)$newmsg);
	}
 
}
 
interface Msg_Decorator_Interface {
	function render(Message $message);
}
 
abstract class Msg_Decorator_Abstract extends Message {
 
	public function __construct(Message $msg) {
		$this->render($msg);
	}
 
}
 
class Li_Decorator extends Msg_Decorator_Abstract implements Msg_Decorator_Interface {
 
	public function render(Message $message) {
		$msg = $message->getMsg();
		$this->setMsg('<ul><li>'. $msg .'</li></ul>');
	}
 
}
 
class Div_Decorator extends Msg_Decorator_Abstract implements Msg_Decorator_Interface {
 
	public function render(Message $message) {
		$this->setMsg('<div>'. $message->getMsg() .'</div>');
	}
 
}
 
class DivClass_Decorator extends Msg_Decorator_Abstract implements Msg_Decorator_Interface {
 
	private $class;
 
	public function __construct(Message $msg, $class = null) {
		$this->class = $class;
		parent::__construct($msg);
	}
 
	public function render(Message $message) {
		$this->setMsg('<div class="'.(null === $this->class?'default-class':$this->class).'">'.$message->getMsg().'</div>');
	}
 
}

OK! Com o código em mãos, vamos pensar um pouquinho. Tenho uma cacetada de classes, todas fazendo praticamente a mesma coisa. E agora? Calma, Juvenal. Vamos analizar:

1. Temos a classe Mensagem. Sabemos que ele representa uma mensagem. Métodos básicos para manipularmos a mensagem e um __toString() que irá retornar o valor em string pra classe quando for feito o cast.
2. Classe Msg_Decorator_Abstract que extende da classe Mensagem. Todos os nossos decoradores, por assim dizer, irão ser filhos desta classe. O exemplo é tão simples que a classe abstrata nem tem métodos abstratos. Mas a idéia é que tenha, caso necessário.
3. Msg_Decorator_Interface, essa interface obriga os programadores que quiserem criar decorators a escrever o método render(). Que é chamado pela nossa classe Abstract no construtor.
4. Li_Decorator, Div_Decorator e DivClass_Decorator são exemplos de decorators.

Vamos ver o negócio funcionando? Vamos escrever o seguinte código:

1
2
3
4
5

   	print new Div_Decorator(
			new Li_Decorator(
				new Message("Mensagem de teste!")
			)
		);

Irá imprimir

1
2
3
4
5

<div>
<ul>
	<li>Mensagem de teste!</li>
</ul>
</div>

Viram? Simples e prático! Claro que o exemplo é bem simples e talvez nem seja tão útil. Mas é só pensar um pouquinho mais que logo surgem exemplos onde se usar o Decorator.

Entender agora fica mais fácil. Apenas comece olhando do meio para a esquerda. Primeiro nós instanciamos a classe Message com o mensagem “Mensagem de teste!”. O método getMsg() retornará exatamente isso: “Mensagem de teste!”. Porém, no momento em que é instanciado o Li_Decorator, ele vai mudar a mensagem usando o método render(), que deve ser implementado na Msg_Decorator_Interface e chamado na Msg_Decorator_Abstract pelo construtor. E assim acontece com o Div_Decorator.

Notem que eu decidi mudar o valor da mensagem usando o setMsg. Eu já li em alguns lugares onde fica armazenada a instância da classe anterior e então o método getMsg seria chamado em forma de cascata, fazendo com que a mensagem original nunca fosse alterada de verdade, e no fim ela é, igual a um método recursivo, retornada decorada e maquiada.

Reutilizando o código

Bom, como eu havia dito no começo, o Observer Pattern nos possibilita o reuso. O exemplo são aquelas duas classes das quais eu não cheguei a falar: Error_Message e Success_Message.

Observem que são simples e, utilizando os Decorators já existentes, mostram uma mensagem personalizada de Erro e de Sucesso! Para utilizá-las, basta usar:

1
2

print new Error_Message("Erro! Você fez algo errado!");
print new Success_Message("Sucesso! Parabéns!");

O que imprimirá:

1
2
3
4
5
6
7
8
9
10

<div class="error-msg">
<ul>
	<li>Error!</li>
</ul>
</div>
<div class="success-msg">
<ul>
	<li>Sucesso! Parabéns!</li>
</ul>
</div>

Prós

• Adiciona flexibilidade ao código.
• Facilmente reutilizada.
• Ótimo para sistemas que possibilitam o uso de plugins.

Contras

• Gera um grande número de arquivos (se for pensar que cada arquivo é uma classe ou vice-versa).
• Dependendo da quantidade de classes aloca muita memória.
• Ruim para sistemas mais fechados e bitolados ou muito padronizados.

Acho que é isto pessoal. O que acharam? Não é um bixo de sete cabeças, né?