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.
Marcado: PHP
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?
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).
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 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.
Marcado: dica, Doctrine, objeto-relacional, orm, PHP
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.
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.
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).
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.
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.
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.
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 é 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.
No php.ini alterei a seguinte diretiva:
max_execution_time = 30
Para:
max_execution_time = 1800
E voilà, funcionou.
Magento instalado com sucesso.
Marcado: instalacao, Magento, PHP, problema, tempo limite
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.
É um padrão de projeto para abstração da camada de persistência com o banco de dados.
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.
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.
Marcado: abstracao, abstracao de banco, dao, data access object, design pattern, mvc, 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.
Marcado: arquitetura de projeto, design pattern, implementacao, mvc, padrao de projeto, PHP
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à.
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 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 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.
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.
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.
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.
Marcado: arquitetura de projeto, controller, design pattern, model, mvc, padrao de projeto, PHP, view
Quando você desenvolve uma aplicação é bom que seu código-fonte fique bem claro e inteligível. Sempre que você cria um código você sabe o que ele faz neste momento, mas passado algum tempo dificilmente você se lembrará do significado daquele método ou o que aquele atributo armazena.
Quando você desenvolve um aplicativo você também tem que garantir que outra pessoa que for dar manutenção em seu código também entenda e para facilitar a vida dos programadores vou citar aqui para os que não conhecem o phpdoc.
O que é?
O PHPDocumentor é uma aplicação desenvolvida em PHP para gerar documentação de acordo com algumas regras e tags que você coloca em seu código. O sistema de trabalho dele é bem parecido com o sistema do javadoc do Java.
Para a geração da documentação o PHPDocumentor trabalha com um sistema de comentários dentro do código, estes são os chamados DocBlocks.
DocBlocks
DocBlocks são os comentários que você terá que incluir no seu código para que possa ser gerada a documentação do PhpDoc.
Para inserir DocBlocks basta colocar as tags de comentário em bloco da seguinte forma:
/** * * Aqui vem os comentários */
Cada docblock deverá ser colocado acima do código, classe, metódo ou atributo que você quer comentar ou especificar.
Existem uma série de tags que você poderá utilizar para que seja definido o seu código.
Tags para documentação – padrão PEAR
Nos meus projetos costumo utilizar o padrão de documentação da PEAR alterando algumas coisas que não são necessárias para mim ou que ficam melhores em outros formatos.
Seguindo este padrão, no início do meu arquivo de classe eu coloco o comentário definindo a classe seguindo estes docblocs, o texto inicial seria a especificação da classe seguindo de algumas tags específicas para definição.
Não vou explicar as tags, pois este não é o objetivo deste post, mas vocês podem ver a lista de tags em: http://manual.phpdoc.org/HTMLSmartyConverter/HandS/phpDocumentor/tutorial_phpDocumentor.pkg.html
E também toda e qualquer documentação sobre o phpdocumentor no site: http://www.phpdoc.org/
Gerando documentação
Para gerar a documentação basta você baixar o phpdocumentor no site acima, coloca-lo em seu apache e executa-lo pelo navegador.
Depois de feito isso você vai entrar na interface do phpdocumentor:
As duas abas principais para a geração de documentação vão ser a “files” e a “output”. Clicando na aba files você poderá ver vários campos, todos possuem suas explicações ao lado, é bem intuitivo.
Você usará esses campos para definir arquivos, pastas e pacotes para que sejam geradas a documentação.
No meu caso, utilizo mais o segundo campo, onde especifico um diretório para que o phpdoc procure os arquivos e gere a documentação.
Na guia output, em target, eu especifico onde serão gerados estes arquivos e o layout de saída deles.
Após isto basta clicar em create ou create (new window) para que o phpdoc gere a documentação no diretório especificado. Depois você pode acessar a documentação abrindo a pasta e executando o index.html.
Marcado: comentario, desenvolvimento, docblock, documentacao, PHP, phpdoc, phpdocumentor
Uma das melhores funcionalidades do XDebug é a integração com a IDE Netbeans com poucas configurações.
Esta integração permite que você possa visualizar e verificar o conteúdo de suas variáveis e objetos e também das variáveis superglobais, acompanhando isso passo-a-passo durante seu código.
Para iniciar a configuração da integração basta abrir o php.ini e adicionar as seguintes linhas:
zend_extension=/opt/lampp/lib/php/extensions/xdebug.so
xdebug.remote_enable=on
xdebug.remote_handler=dbgp
xdebug.remote_host=localhost
xdebug.remote_port=9000
A primeira linha é onde você configura o endereço da extensão do Xdebug, este passo foi mostrado no post anterior.
As linhas seguintes são configurações solicitadas pelo Netbeans para que ele possa se conectar ao depurador.
Depois de adicionada estas linhas basta você executar a depuração do próprio Netbeans:
Depurar projeto php no netbeans
E durante a depuração você verá a seguinte interface:
