Latest Entry
Jul 31, 2010 Design Patterns
Command é um padrão de projeto comportamental utilizado para melhorar o fluxo da aplicação encapsulando as requisições feitas como objetos.
No command não é importante como os objetos são chamados, pois todos os objetos são parametrizados implementando uma interface OO.
Implementando Command em PHP
A implementação do command é bem simples, seguindo os moldes da arquitetura MVC ele estará situado no controller e cada ação será chamado por um objeto que implementa uma interface Action.
Interface:
<?php
interface Action {
public function execute();
}
Esta interface é responsável por parametrizar todas as ações do controller. Já que como não é importante saber sobre a instanciação da classe nós precisamos, ao menos, ter um ponto de partida padrão para que seja chamada nossa ação.
Esta nossa interface define o escopo da classe que implementará a interface, isto quer dizer que sempre que criarmos uma classe que implementa Action, a classe deverá possuir o método público execute().
Ação:
<?php
require_once 'Action.php';
class NovoUsuarioAction implements Action {
public function execute() {
// implementação da ação do método execute
require_once 'view/FormNovoUsuario.php';
}
}
Nossa classe que implementa o método execute realiza uma ação qualquer de fluxo e chama uma view correspondente.
Instanciando e controlando o fluxo das Actions
Agora vamos ver como faremos para instanciar nossas actions. Volto a repetir que como as actions são instanciadas não é importante, elas serão instanciadas automaticamente durante a execução da aplicação, mas, por não ser importante como são instanciadas, precisamos estabelecer um padrão para uma instanciação automática.
Para fazer isto vamos implementar uma classe Command (neste exemplo).
<?php
class Command {
public function __construct($action) {
require_once $action.'Action.php';
$action .= 'Action';
$obj = new $action;
$obj->execute();
}
}
Como podemos observar, a nossa classe Command recebe uma action e é ela que é responsável por fazer um require importando a classe e também instanciando e executanto o método execute que foi implementado anteriormente.
Para a action ser instanciada precisamos passar ao Command a action que deverá ser realizada, podemos fazer isto no index.php através de uma query string:
<?php
require_once 'Command.php';
$action = $_GET['action'];
$command = new Command($action);
Desta forma então, quando acessarmos a url http://seu.domínio/index.php?action=NovoUsuario a aplicação instanciará automaticamente nossa action, realizando as ações determinadas e chamando a view específica.
Neste caso estou utilizando a super-global $_GET para pegar a query string, para uma melhor segurança você poderia utilizar os filtros do php para sanitizar esta string e evitar problemas com quebra de segurança. Se você não conhece estas funções, basta dar uma olhada no manual do PHP na parte de Data Filtering.
Recent Entries
Jun 16, 2010 Wordpress
Recentemente tive um problema para conseguir gerar o feed do wordpress.
Ao acessar o xml do feed era acusado um problema na geração devido à um espaço antes da marcação xml.
Existem plugins próprios para este tipo de verificação e algumas técnicas disponíveis na internet para retirar este espaço. Nenhuma destas alternativas deu certo.
A solução para este problema esta no próprio arquivo do tema do wordpress, mais precisamente no functions.php.
O problema eram sucessões de tags php abrindo e fechando (o problema era na tag de fechamento), como é documentado pelo PHP o fechamento de tag php pode acabar gerando um caracter em branco que, no meu caso, estava dando problema na geração do feed.
Bastou normalizar este arquivo que o feed voltou a ser gerado.
Jun 9, 2010 PHP
Micro-post para dar meus parabéns ao PHP.
Esta linguagem fantástica lançada por Rasmus Lerdorf há 15 anos atrás.
Hoje trata-se de uma linguagem madura e versátil que é o ganha-pão de muitos profissionais conceituados no mundo da informática.
Jun 7, 2010 Biblioteca, Doctrine
Quem nunca se perguntou: Por quê as operações com o banco de dados não são mais simples?
Uma das tarefas mais massantes no desenvolvimento de um sistema, sem dúvida, é a camada de abstração do banco de dados. Para se realizar uma consulta, inserção, alteração ou exclusão precisávamos sempre escrever queries sql que deixavam o código sujo e bagunçado, sem falar que a portabilidade entre os sgdb’s eram quase nulas, raras exceções implementadas para facilitar a nossa vida.
Com o surgimento da POO e a adoção desta técnica pelo PHP apareceu também uma útil extensão (que espero que todos já estajam usando) o PHP Data Objects, para os íntimos PDO, que é uma mão-na-roda para qualquer desenvolvedor que se preocupe um pouco com portabilidade.
Com o PDO a conexão ao banco é uniforme, apenas passamos os dados necessários e voilà, o próprio PDO se preocupa em como conectar, acabando com os desconsertantes mysql_connect e pgsql_connect que eram muito usados, porém pouco práticos. Agora com um simples DSN (data source name) e suas configurações:
<?php
// antes
$conn = mysql_connect('host','usuario','senha');
$db = mysql_select_db('db',$conn);
// depois
$pdo = new PDO('mysql:host=host;dbname=db','usuario','senha');
$pdo2 = new PDO('pgsql:host=host2;dbname=db','usuario',senha');
Percebeu a diferença? Não precisamos mais chamar aquele monte de funções para fazer uma simples conexão com o banco. Nada mais de ficar decorando nome de funções para chamar seus bancos mysql, postgresql entre outros, agora apenas trabalhamos com o PDO, uma evolução entanto do PHP, mas…
Mesmo com todas as facilidades advindas do desenvolvimento do PDO ainda precisamos escrever as nossas velhas conhecidas queries sql, será que ninguém pensou em nada mais fácil?
Objeto-relacional, como não pensei nisso antes!?
Bom, estamos na era do desenvolvimento orientado à objetos (mais que isso, na era da modularidade) e porquê ainda utilizamos bancos relacionais? Bom, temos hoje em dia alguns bancos que são totalmente orientados à objeto e orientados à documentos e outros bancos, mas eles ainda não estão tão pertos do uso comercial assim, então como poderíamos aproveitar melhor o paradgma da orientação à objeto em nossos bancos relacionais?
Acertou quem faleu pelo mapeamente objeto-relacional, que nada mais é que uma biblioteca que vai trabalhar entre a sua aplicação e o banco de dados e vai normalizar todas as requisições que forem feitas.
No mapeamento de objeto-relacional as tabelas do banco de dados são tratadas como classes de sistemas e os registros de cada tabela são objetos (instâncias) destas classes e por consequência as antigas queries complexas são substituídos por chamadas à métodos da biblioteca ORM.
Para os fãs de frameworks o objeto-relacional é muito conhecido como Active Records (para quem usa code igniter, yii e zend framework) e eles trabalham mais ou menos da mesma forma que um verdadeiro ORM.
Bom, como você já deve ter percibido, se fazemos nossas consultas por métodos não precisamos mais escrever queries (pelo menos se você não quiser).
Doctrine
Já tentei usar trabalhei com algumas ferramentas para mapear objetos-relacionais e a que melhor se encaixou às minhas necessidades foi o Doctrine, projeto este muito bem desenvolvido e coordenado, feito com base no famoso (e todo poderoso) Hibernate, utiliza-se de uma linguagem própria, DQL – Doctrine Query Language, criada através da chamada de métodos, que depois será convertida em SQL.
Esta biblioteca é muito simples, porém robusta e sua versão estável está na 1.2, sendo que será lançada a versão 2.0 em breve.
Com está biblioteca eliminei a maior parte do código que estava engordurando o meu DAO das minhas aplicações, porém infelizmente não pude continuar usando esta ferramenta.
Doctrine 1.2 cumpre o seu papel de forma primorosa com a ressalva que (nenhum das bibliotecas que testei atendeu este critério) o modo que elas tratam os joins do sql e seus correspondentes em classes (ou pelo menos deveriam ser) não é o melhor possível. O natural para quando se faz uma consulta em uma tabela que possui chave estrangeira seria uma associação entre duas classes e nisto o doctrine pecou na sua versão 1.2. Como na época precisava deste tipo de função resolvi não levar em frente meus estudos, porém…
Doctrine 2.0 – o retorno
Doctrine 2.0 já está em sua fase beta e promete fazer o diferencial para os outros ORM’s PHP, prova disto é que finalmente foi implementado o suporte a criação de objetos-relacionais por annotations, que são aquelas anotações que colocamos nos docblocks para gerar comentários e também uma grande melhoria na associação entre classes.
Este post vale mais pela definição do que é um ORM e a sugestão para testarem e usarem o Doctrine em seus projetos, com certeza é um grande complemento que facilita a pedância de ter que escrever queries e mais queries.
Apr 25, 2010 Frameworks, Yii Framework
Yii framework é um excelente framework php de alta performance.
Permite criação de um projeto de forma rápida apesar da curva de aprendizado deste framework ser um pouco mais elevado que de outros, o que é compensado por suas funcionalidades.
Eu, em um primeiro momento, senti dificuldades em encontrar documentação para este framework, porém no site dele possui guias bastante interessantes que abordam grande parte do framework e ajudam no aprendizado.
Para começar o uso do framework iremos baixar do site do desenvolvedor: yiiframework.com. Baixe também a documentação para futuras consultas e informações sobre ele.
Descompacte o arquivo que baixou. Dentro da pasta descompactada existem várias outras pastas e arquivos. A que nos interessa é a pasta framework.
Preparando para a criação de um projeto
Antes de começar a trabalhar com o framework precisamos definir algumas coisas que são de suma importância para o aproveitamento total da criação de um projeto rápido com o Yii.
Vamos, neste momento, criar nosso banco de dados. Como estamos fazendo somento um exemplo vou criar um banco simples simulando uma agenda.
O script para a criação deste banco será:
CREATE DATABASE agenda;
USE agenda;
CREATE TABLE agenda (
id INT NOT NULL PRIMARY KEY,
nome VARCHAR(255) NOT NULL,
telefone VARCHAR(10) NOT NULL
) CHARACTER SET utf8 COLLATE utf8_unicode_ci;
Criado nosso banco vamos começar a trabalhar com o Yii Framework.
No diretório de projetos do apache (htdocs, www, …) crie uma pasta com o nome agenda. Esta pasta será a raiz do nosso projeto.
Copie a pasta framework (pasta descompactada do Yii) para dentro desta pasta e vamos criar nosso projeto.
Criando um novo projeto
Para a criação de um novo projeto Yii no Ubuntu é necessário criar via linha de comando, então abriremos o terminal e utilizaremos o seguinte código:
caminho/para/php /caminho/para/pasta/framework/yiic webapp /caminho/para/pasta/raiz
No meu caso (utilizo XAMPP) usaria o seguinte comando:
/opt/lampp/bin/php-5.3.0 /opt/lampp/htdocs/agenda/framework/yiic webapp /opt/lampp/htdocs/agenda
Após executar este comando ele vai perguntar se desejamos mesmo criar um novo projeto. Basta responder ‘y’.
Após isso será criado toda a estrutura de pastas do projeto com um demo já criado com opção de login e afins. Você pode acessar pelo endereço http://localhost/agenda (no meu caso).
Configurando uma conexão
Até aí já temos nosso projeto criado, agora vem uma das partes interessantes do Yii Framework.
Vamos criar os modelos de nossa arquitetura MVC direto das nossas tabelas no banco de dados, mas para isso precisamos estabelecer uma conexão.
Dentro do projeto agenda vamos acessar o arquivo main.php que está em /agenda/protected/config.
Neste arquivo encontramos diversas configurações do framework. A configuração que nos interessa neste momento é a de banco de dados que está com a flag ‘db’ dentro do array de configuração.
Já existe como comentário uma conexão MySql, basta alterar estas informações para se conectar ao seu banco.
Como ele utiliza a conexão PDO, nativa do PHP, basta você alterar seu DSN para se conectar à qualquer banco que desejar.
Alterado este arquivo vamos voltar à linha de comando.
Gerando modelos
Com nossos dados de conexão estabelecidos voltaremos a linha de comando. Lá vamos trabalhar com o seguinte código:
caminho/para/php /caminho/para/pasta/framework/yiic shell /caminho/para/pasta/raiz/index.php
No meu caso:
/opt/lampp/bin/php-5.3.0 /opt/lampp/htdocs/agenda/framework/yiic shell /opt/lampp/htdocs/agenda
Com isso entraremos em um console do Yii. Para gerar os modelos basta invocar esta opção:
>> model *
Com isto você cria modelos de todas as suas tabelas do banco de dados, caso queira criar modelos de apenas algumas tabelas basta utilizar:
>> model agenda
Onde ‘agenda’ é o nome da tabela que deseja referenciar.
Se você for até a pasta de modelos (/agenda/protected/models) você verá que os modelos já estão lá com suas regras de acordo com o banco de dados.
CRUD com Yii
Vamos agora criar nosso CRUD para nosso modelo.
O CRUD, como abordado em outros posts, é o termo que refere nossas ações comuns no banco de dados (inserir, excluir, atualizar e buscar).
O Yii já cria isso tudo para você, basta, dentro de sua interface em linha de comando, utilizar o comando:
>> crud Agenda
Neste momento o própria Yii cria todas as interfaces e tarefas para o cadastro, alteração exclusão e busca de itens do banco de dados de acordo com a conexão especificada.
Todas as regras de validação utilizadas pelo framework são baseadas nas tabelas do banco, mas isto poderá ser alterado mais para frente.
Para acessar o CRUD você precisa acessar o sistema do Yii e fazer log in. Acesse a url do seu projeto (http://localhost/agenda/index.php?r=agenda) e voilà, já pode cadastrar contatos da agenda.
Apr 20, 2010 Ferramentas, Magento
Magento para quem não conhece é uma solução de e-commerce gratuita desenvolvida em PHP com base de dados MySQL.
É, hoje em dia, uma das melhores soluções para e-commerce existente e abrange muitos fatores para promoções de produtos entre outras. Foi desenvolvido com o raciocínio voltado totalmente para módulos, quem quiser conhecer o projeto basta acessar http://www.magentocommerce.com/ e conferir.
Bom, chega de babação de ovo, estou escrevendo este artigo pois tive um problema na instalação do magento no meu servidor local.
O problema
O problema é muito conhecido por várias pessoas: tempo máximo de execução. Como o banco de dados do Magento é muito grande acabou por ultrapassar o limite máximo de tempo de execução padrão do php.
A solução
No php.ini alterei a seguinte diretiva:
max_execution_time = 30
Para:
max_execution_time = 1800
E voilà, funcionou.
Magento instalado com sucesso.
Mar 26, 2010 Design Patterns, PHP
Data Access Object ou DAO é um padrão de projetos desenvolvido para melhorar a forma como trabalhamos com abstração de banco de dados.
Neste conjunto de classes (adiantando, faz parte do nosso modelo) você especifica toda a interação da aplicação com o banco.
É responsável pelas rotinas de consulta, exclusão, alteração, inserção.
O que é?
É um padrão de projeto para abstração da camada de persistência com o banco de dados.
Por quê usar?
Por centralizar toda a sua interação com o banco de dados em um conjunto de classes é mais fácil para você proteger seu banco fazendo com que dados importantes não sejam expostos em outras partes do seu código.
Separa interamente seu código, faz com que a parte lógica e as regras de negócio fiquem isoladas de toda persistência com o banco de dados.
Utilização junto com MVC
O DAO faz parte do modelo de uma arquitetura MVC, com a implementação de mais esse padrão de projeto você pode retirar do seu módulo em si todos os métodos relativos ao banco tornando seu objeto melhor contextualizado.
Segue um exemplo de modelo:
<php
class Cliente {
private $nome;
public function getNome() {
return $this->nome;
}
public function setNome($nome) {
$this->nome = $nome;
}
}
Implementação do modelo DAO
<?php
require_once 'caminho/para/classe/Cliente.php';
class ClienteDAO {
public function save(Cliente $cliente) {//lógica para salvar o objeto no banco}
public function update(Cliente $cliente) {//lógica para atualizar o objeto no banco}
...
}
Como pode ser observado, todos os dados serão armazenados em nosso modelo. O nome do cliente fica armazenado no nosso objeto cliente, quando há necessidade de salvar (ou alterar, buscar, excluir) este cliente no banco acessamos nosso DAO para realização desta tarefa.
Segue como ficaria nosso Controller com a implementação do DAO:
<?php
require_once 'caminho/para/classe/ClienteDAO.php';
class ClienteController {
public function salvar() {
$nome = $_POST['nome'];
$cliente = new Cliente();
$clientedao = new ClienteDAO();
$cliente->setNome($nome);
$clientedao->save($cliente);
}
}
Aqui estou pegando o nome digitado por um usuário via POST e passando para o meu objeto Cliente. Para salvar o nome no banco de dados chamei minha classe DAO para realizar a tarefa.
Mar 14, 2010 Design Patterns, PHP
Bom, agora que já foi passado o conceito de MVC, vamos exemplificar sua funcionalidade usando o PHP.
Implementando MVC no PHP
Primeiramente vamos começar implementado nosso modelo:
<?php
class Cliente {
private $id;
private $nome;
/**
* ...
* getters e setters
* ...
*
*/
public function save() {
// logica para salvar cliente no banco
}
public function update() {
// logica para atualizar cliente no banco
}
public function remove() {
// logica para remover cliente do banco
}
public function listAll() {
// logica para listar toodos os clientes do banco
}
/**
* ...
* outros métodos de abstração de banco
* ...
*
*/
}
?>
O modelo, como foi falado antes, é responsável pela abstração do banco de dados. Por isso, todos os métodos que acessarão o banco de dados para modificações ou retornos devem ser desenvolvidos no modelo.
Seguindo com a estrutura, vamos criar uma view com a listagem dos clientes:
<?php
$clientes = $_REQUEST['clientes'];
?>;
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<title>Implementando MVC</title>
</head>
<body>
<table>
<tr>
<th>ID</th>
<th>Cliente</th>
</tr>
<?php foreach ($clientes as $cliente): ?>
<tr>
<td><?php echo $cliente->getId(); ?></td>
<td><?php echo $cliente->getNome(); ?></td>
</tr>
<?php endforeach; ?>
</table>
</body>
</html>
A visão tem como papel receber os dados do controle e exibir para o usuário. Como podemos ver no código acima, a view está recebendo um request com um vetor de objetos cliente que são exibidos em tela com um foreach.
Ainda seguindo a estrutura, vamos ao controller:
<?php
require_once 'model/Cliente.php';
class ClienteController {
public function listar() {
$cliente = new Cliente();
$clientes = $cliente->listAll();
$_REQUEST['clientes'] = $clientes;
require_once 'view/cliente_view.php';
}
}
?>
No controle nos apenas chamamos nosso modelo, que é a classe responsável pela abstração. Ao recuperarmos os dados, mandamos para a nossa visão.
Para chamar tudo isso, no index.php usaremos o seguinte código:
<?php</pre>
$classe = $_GET['class'];
$metodo = $_GET['acao'];
$classe .= 'Controller';
require_once 'controller/'.$classe.'.php';
$obj = new $classe();
$obj->$metodo();
?>
A nossa estrutura de pastas fica da seguinte forma:
/ (raiz)
– controller/
– model/
– view/
index.php
Esta foi uma implementação simples da arquitetura de projeto MVC, foi apenas um incentivo para que todos possam implementar este padrão de projeto e deixar o código mais fácil e o desenvolvimento mais rápido. Vale à pena estudar estes padrões.
Espero ter sido claro, qualquer dúvida basta contatar-me.
Mar 11, 2010 Uncategorized
Um tempo atrás estava eu trabalhando com Fusion Charts, que é um sistema para geração de gráficos em flash (muito interessante, por sinal).
Em alguns gráficos me deparei com os seguintes caracteres: 
Intrigado com isto fui pesquisar e acabei encontrando o significado:
Estes caracteres são os caracteres B.O.M. (Byte Order Mark) do Fusion Charts. Tá, mas pra que me serve saber isso?
Simples. Estes caracteres são gerados quando seu código-fonte não está na codificação correta do fusion charts, ou seja, quando você não está trabalhando com UTF-8.
Como eu não podia, neste caso específico, mudar a codificação da página inteira, bastou eu mudar o header somente do gráfico com o header do php.
<?php header(‘Content-type: text/html; charset=utf-8′); ?>
E voilà.
Feb 25, 2010 Design Patterns, PHP
Existe muita coisa entre o desenvolvimento de alto nível e o copy & paste do que a vã filosofia de um sobrinho é capaz de entender.
Dentre essas coisas estão os padrões de projetos (design patterns) e à partir deste post falarei um pouquinho sobre eles.
Nesta primeira parte explicarei um pouco do conceito sobre o desenvolvimento em 3 camadas e na segunda parte farei um exemplo de implementação em php.
Design Patterns? Isso morde?
Design patterns ou padrões de projetos são, nada mais nada menos, que um modo de desenvolvimento. Segue-se determinadas regras do padrão adotado para solução de determinado problema, normalmente inerente à programação orientada à objetos.
É muito utilizado devido o grau de abstração que se consegue através destas práticas, tornando o código muito mais legível e de fácil manutenção e crescimento.
MVC – Model, View, Controller
MVC não foi criado para ser somente um padrão de projeto, ele na verdade é uma arquitetura de projeto onde seu objetivo é separar seu código em três camadas fazendo com que cada área só trabalhe com itens que competem à elas. Trocando em miúdos, cada um só faz o que foi desenvolvido para fazer.
Com o MVC você facilmente transforma seu código de modo à ficar muito mais legível.
Para utilizá-lo você tem que ter em mente que haverá uma separação em seu código, as regras de negócio ficarão separadas da lógica e da interface do usuário.
M de Model
O model, ou modelo, no padrão MVC serve para armazenar e persistir os dados. O que seria isso? Toda comunicação com o banco de dados. Os comandos crud (inserir, alterar, remover, buscar) serão feitas pelas classes deste tipo.
É utilizado para armazenar informações,trabalhando como um espelho da tabela do banco de dados. Como trabalhamos com objetos, os dados serão persistidos como objetos.
V de View
O view, ou visão, no padrão MVC servirá APENAS para exibir as informações enviadas pelo controller, aqui não existirá nenhuma lógica ou regra de negócio, apenas a interface do usuário.
C de Controller
O controle faz exatamente o que o nome diz: controla. Ele é o responsável por fazer o intermédio entre o modelo e a visão.
É o responsável também por toda lógica do sistema. Retornando somente os itens necessários para a comunicação entre o modelo e a visão. Entre o usuário e a aplicação.
