ShareThis

Segue o link do post

ShareThis

Por favor, não levem muito em conta o design, sou péssimo usuário de programas como GIMP (que estou usando) ou Photoshop. Mais adiante eu vou procurar algum amigo que tenha a “manha” desses programas e me ajude com um layout mais legalzinho.

No próximo post mostrarei a validação (usando Zend_Input_Validate, jQuery, XML) desta tela, por isso propositalmente apresento aqui a tela de cadastro de usuários e não a página inicial do site.

ShareThis

Sendo o Zend_Controller um componente com muitas funcionalidades, neste momento, vou apresentar apenas o básico, que é o que está sendo utilizado no projeto até o momento.

O inicio de tudo já foi até explicado superficialmente no post sobre a organização do projeto, tudo começa na estrutura, por isso, vou apenas copiar algumas partes que foram descritas lá.
Estrutura de diretórios:

../
../application
../application/default/controlers
../application/default/models
../application/default/views
../html
../html/images
../html/scripts
../html/styles
../html/index.php
../html/.htaccess
../library

Também faz parte do setup do Zend_Controller o arquivo .htaccess que contém algumas regras de re-escrita de URL.

RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php

O index.php é o nosso “pontapé” (bootstrap), todas as requisições são através dele.

<?php
/**
* @author Andre de Castro Zorzo
* @version
*/
set_include_path('.' . PATH_SEPARATOR . '../' . PATH_SEPARATOR . '../library' . PATH_SEPARATOR . './application/default/models/' . PATH_SEPARATOR . get_include_path());
require_once 'Zend/Controller/Front.php';
/**
* Setup controller
*/
$controller = Zend_Controller_Front::getInstance();
$controller->setControllerDirectory('../application/default/controllers');
$controller->throwExceptions(true); // XXX deixar ligado apenas enquanto estiver desenvolvendo
$controller->dispatch();
?>

Esse “$controller->setControllerDirectory(’…’)” indica o diretório onde estão as “controllers” do projeto. E o “$controller->dispatch()” é o responsável por procurar as “controllers” nesse diretório e “despachá-las”, (fazê-las rodar/executar).

Um pouquinho sobre como funciona o roteamento das urls.

A primeira parte da url indica qual “controller” chamar, e a segunda, qual “action”. Assim, http://urlcurta.com/cadastro/editar significa que “cadastro” é a nossa “controller” e “editar” a nossa “action”. Por padrão, quando não é informada uma “action”, o Zend Framework, assume a “index” como sendo a “action” da controller “cadastro”. E se não informar uma “controller”, por padrão o Zend Framework assumirá a controller “index”, exemplificando:

http://urlcurta.com/cadastro/editar (controller "cadastro", action "editar")
http://urlcurta.com/cadastro (controller "cadastro", action "index")
http://urlcurta.com (controller "index", action "index")

Pela definição que fizemos anteriormente, no arquivo “index.php”, nossas controllers estão no diretorio “application/default/controllers”.

Para o nome das controller e actions existe uma regra a ser seguida, por definição do Zend Framework, o nome de uma controller DEVE começar com letra maiúscula e terminar com a palavra “Controller” (a primeira em maiúscula também), por exemplo, “CadastroController.php“. Assim, temos os arquivos:

application/default/controllers/CadastroController.php
application/default/controllers/IndexController.php

Para “actions” a regra é, o nome seguido pela palavra “Action” (a primeira em maiúscula), por exemplo “editarAction”.

É possivel definir nomes compostos para controllers e actions, porém, você deve observar um detalhe, digamos que a controller seja: “TermosDeUsoController.php”, para isso funcionar corretamente, você deverá chamar na url: http://urlcurta.com/termos-de-uso, se tentar usar http://urlcurta.com/termosDeUso vai dar erro e não vai funcionar.

Agora vamos ver o código da controller “CadastroController.php”

<?php
/**
* CadastroController
*
* @author Andre de Castro Zorzo <andre_zorzo@yahoo.com>
* @version
*/
require_once 'Zend/Controller/Action.php';
class CadastroController extends Zend_Controller_Action
{
public function indexAction()
{
}
public function editarAction()
{
}
}


E o IndexController.php está assim

<?php
/**
* IndexController - The default controller class
*
* @author Andre de Castro Zorzo <andre_zorzo@yahoo.com>
* @version
*/
require_once 'Zend/Controller/Action.php';
class IndexController extends Zend_Controller_Action
{
public function indexAction()
{
}
}

Além disso, temos um “action helper” chamado ViewRenderer que está ativo por padrão, isso significa, que o simples fato de criar uma “action” e um arquivo html (view) o conteúdo deste arquivo de “view” já será apresentado. Mais um componente que está ativo por padrão, e que é a parte da camada MVC é o Zend_View. Para determinar o nome da view correspondente, o ViewRenderer através do nome da controller e da action descobre qual é template (view/codigo html). A extensão padrão dos templates é “.phtml”, assim, a url http://urlcurta.com/cadastro/editar vai utilizar o template que fica no diretório:

application/default/view/scripts/cadastro/editar.phtml

<html>
<title>Projeto URLcurta!</title>
<body>
<h1>Editar Cadastro</h1>
</body>
</html>

Basicamente é isso o Zend_Controller. Nos próximos posts provavelmente abordarei mais um pouco de Zend_Controller. Qualquer duvida, é só falar!

ShareThis

Agora começa a parte legal do negócio, vou tentar explicar de forma simples e objetiva cada uma das coisas que usei no “bootstrap”.

Zend_Config e Zend_Config_Xml

O Zend_Config serve para simplificar a forma de acessar dados de configuração dentro de um sistema. Você pode ter os dados de configuração em arquivo XML, usado no caso do projeto URLcurta, ou arquivo “INI”. Para isso você tem “adaptadores” ou “interfaces” para acessar os arquivos contendo os dados de configuração, abaixo você verá o arquivo “config.xml” usado no projeto:

<?xml version="1.0" encoding="UTF-8"?>
<configdata>
<production>
<webhost>urlcurta.com</webhost>
<database>
<adapter>pdo_mysql</adapter>
<params>
<host>localhost</host>
<username>root</username>
<password></password>
<dbname>urlcurta</dbname>
</params>
</database>
</production>
<development extends="production">
<database>
<params>
<dbname>dev_urlcurta</dbname>
</params>
</database>
</development>
</configdata>

Uma coisa que eu achei bem interessante nisso, é que você pode ter varias configurações dentro deste mesmo arquivo, como no exemplo acima, onde o banco de dados “development” extende as configurações do banco de dados “production”, assim, você não precisa ficar se preocupando em sempre configurar os dados de conexão quando faz uma nova release do projeto, os dados já estão lá. Outro ponto interessante que isso possibilita organizar de forma simples os dados quando você tem um sistema que acessa vários bancos de dados.

Nesse caso, para usar o banco “development”, o código ficaria assim:

$config = new Zend_Config_Xml('../setup/config.xml', 'development');

Zend_Registry

O Zend_Registry é uma alternativa ao uso daquelas variáveis globais, $_GLOBALS, ele permite armazenar objetos, variáveis simples e arrays, por exemplo, e compartilhá-lo atraves de todo o sistema. Vale ressaltar que é diferente do $_SESSION.
No projeto URLcurta, vamos usar o Zend_Registry, apenas para guardar a conexão do banco de dados, para diminuir o tempo que normalmente se perde abrindo e fechando a conexão (preciso confirmar se isso acontece realmente, fazendo alguns testes). Também pretendo fazer testes de carga/stress mais adiante para saber quão eficiente é esse método, se o site tiver uma audiência grande, talvez não seja possivel usar assim. Pois cada usuario segurando uma conexão poderia estrapolar o limite máximo de conexões do mysql/servidor.

O Zend_Registry é uma classe muito simples, nem precisa instanciar:

para adicionar um objeto, um array ou uma variável simples, o método é sempre o mesmo:

Zend_Registry::set(’db’, $db_adapter);

para pegar de volta o valor guardado, pode variar um pouco, mas a forma comum é:

$db_adapter = Zend_Registry::get(’db’);

para saber se um determinado valor está no “registry”, use assim:

if (Zend_Registry::isRegistered(’db’)) {
// sim, esta registrado
}

Quando eu digo que pode variar um pouco, a forma como pegar de volta o valor que está no registry, é porque em alguns casos você pode querer iterar o “registry”, etc. Tambem não pretendo aprofundar muito aqui, então, qualquer duvida você pode consultar o manual: http://framework.zend.com/manual/en/zend.registry.html, e se ainda assim tiver duvidas, você pode perguntar que eu tentarei ajudar.
Zend_DB::factory

Zend_DB::factory tem uma documentação bastante extensa, por isso, neste ponto, vou falar apenas do método factory, e a medida que vou postando mais detalhes sobre o projeto, vou esclarecendo outros métodos e classes que extendem Zend_DB.

O metodo factory (fábrica) simplifica a utilização dos adaptadores de acesso a banco de dados disponiveis no Zend Framework, poderia sem qualquer problema simplesmente instanciar diretamente o adaptador Zend_DB_Adapter_PDO_Mysql, mas o factory simplifica isso, por dinamicamente carregar essa classe, que foi especificada no arquivo de configuracao (vide config.xml “<adapter>PDO_Mysql</adapter>”).

Tem um ponto interessante para considerar aqui, o simples fato de chamar o “Zend_DB::factory” não conecta no banco de dados, a conexão será aberta no momento que for solicitada (por isso disse antes que precisava confirmar se isso não vai contra o que eu falei sobre o tempo perdido abrindo e fechanco conexão).

Concluindo essa parte, e seguindo a lógica do código, se ainda não houver um registro de Zend_DB, instanciamos Zend_Config_Xml, criamos um objeto de conexão com o banco de dados com o Zend_DB::factory e guardamos no registry (acho que poderiamos chamar $_GLOBALS) com o Zend_Registry.
Por enquanto é isso, no próximo post vou falar sobre Zend_Controller.

ShareThis

O ponto inicial de estudo foi o guia de referencia do framework, http://framework.zend.com/manual/en/, parece que tem um pessoal se dedicando a tradução em português do Brasil (se alguém quiser colaborar acesse esse endereço: http://framework.zend.com/wiki/display/ZFDEV/Brazilian+Portuguese), por enquanto estou seguindo essa versão em inglês mesmo, o manual aparentemente esta completo, porém, senti falta de mais detalhes e exemplos, alguma coisas ficam meio confusas a primeira vista e não é raro as vezes que você precisa ler 2 ou 3 vezes um capitulo inteiro para compreender o funcionamento de algumas coisas. Por isso acho que alguns exemplos facilitariam a compreensão.

Agora falando em códigos, o primeiro passo foi definir a estrutura da aplicação, como sendo este um projeto de estudo, optei por fazer o básico, sem módulos, tudo dentro do modulo “default” do framework. E assim ficou organizado:

../
../application
../application/core
../application/default/controlers
../application/default/models
../application/default/views
../html
../html/images
../html/scripts
../html/styles
../html/index.php
../html/.htaccess
../library

No diretorio “application”, que deve ser mantido fora do “document_root” por questões de segurança, e onde ficará todo o código do projeto.

No diretorio “application/core” vão ficar algumas classes, como a classe de validação e outras, que não cabem em outro lugar nessa estrutura, com isso também, a medida que o projeto cresce, e que poderá ser acrescentado algum modulo, é possivel re-utilizar esse codigo e a organização das classes de negocio fica legal. Ficaria estranho, ao meu ver, o modulo “blog” por exemplo, chamar a classe validação de dentro do modulo “default”. Apenas uma questão de organização e estética

No diretório “html”, além das imagens, folhas de estilo e javascript, tem o arquivo “index.php” que é responsável pelo “dispatch” das requisições. Quando eu falar em arquivo de “bootstrap” é desse arquivo que estou falando. Também teremos um arquivo “.htaccess” que contém algumas regras de re-escrita de url, para que tudo seja direcionado ao bootstrap, assim, a aplicação possui um único ponto de entrada, uma das premissas do modelo MVC.

Todas as configurações devem ser inicializadas no bootstrap, para isso vamos criar um arquivo “config.php”, que vai conter algumas informações para inicializar a aplicação, diretórios para o “include_path”, configurações do banco de dados.

E por ultimo, no diretório “library” e onde ficam todos os códigos do zend framework, simplesmente descompactando o arquivo ali dentro.

Acredito que com essa explicação, você já tenha uma noção de como organizar o seu projeto com zend framework. E apartir de agora, vamos começar a ver códigos mesmo.

Começamos então pelo “.htaccess” que é bem simples, por enquanto, provavelmente terei que fazer alguma modificação posterior:


RewriteEngine on
RewriteRule !\.(js|ico|gif|jpg|png|css)$ index.php


Isso significa que qualquer coisa digitada na url, que não seja “.js”, “.ico”, “.gif”, “.jpg”, “.png” ou “.css” vai redirecionar para o index.php (nosso bootstrap).

E agora o index.php (bootstrap):

<?php
/**
* @author Andre de Castro Zorzo <andre_zorzo@NOSPAM.yahoo.com>
* @version
*/
set_include_path('.' . PATH_SEPARATOR . '../' . PATH_SEPARATOR . '../library' . PATH_SEPARATOR . './application/default/models/' . PATH_SEPARATOR . get_include_path());
require_once 'Zend/Db.php';
require_once 'Zend/Config.php';
require_once 'Zend/Config/Xml.php';
require_once 'Zend/Controller/Front.php';
require_once 'Zend/Registry.php';
require_once 'Zend/Session/Namespace.php';
require_once 'Zend/Auth.php';
/**
* Setup database
*/
if (!Zend_Registry::isRegistered('db')) {
$config = new Zend_Config_Xml('../setup/config.xml', 'production');
$db = Zend_Db::factory($config->database);
Zend_Registry::set('db', $db);
$db->getConnection();
}
/**
* Setup controller
*/
$controller = Zend_Controller_Front::getInstance();
$controller->setControllerDirectory('../application/default/controllers');
$controller->throwExceptions(true); // XXX deixar ligado apenas enquanto estiver desenvolvendo
$controller->dispatch();
?>

O primeiro passo nesse arquivo, como comentei anteriormente, é indicar os caminhos das bibliotecas e outros códigos, na sequência, estou incluindo algumas classes, definimos o “setup” do banco de dados, definimos o “setup” do front controller e fazemos o dispatch.

No próximo post eu explicarei brevemente o uso do Zend_Config, Zend_Config_Xml, Zend_Registry e Zend_DB::factory.

ShareThis

Minha intenção é estudar o framework de desenvolvimento, Zend Framework, desenvolvido em PHP5.

Por isso, a medida que o desenvolvimento vai acontecendo, irei postando trechos do código utilizado nesse projeto, e explicando o porquê disso e daquilo e se possivel, ainda darei dicas de como tirar melhor proveito desse framework. Ao final, terei produzido um material o mais didático possivel, com a garantia de funcionamento.

Para realmente estudar o negócio, me propus a desenvolver um projeto aberto ao publico, para outros programadores possam dar seus “pitacos”, e que será mantido gratuitamente como um serviço para usuários da rede. Sem um propósito acho que o estudo não vai render. Por isso, além do tempo investido, estou pagando um hosting para o projeto, assim fico na obrigação de colocá-lo no ar.

A idéia é desenvolver um sistema, baseado no famoso tinyURL, um site que permite aos usuários criar atalhos para URLs muito longas, como nesse exemplo, encontrado no próprio tinyURL:

Transforme essa URL:

http://www.mapquest.com/maps/map.adp?ovi=1&mqma
p.x=300&mqmap.y=75&mapdata=%252bKZmeiIh6N%252bI
gpXRP3bylMaN0O4z8OOUkZWYe7NRH6ldDN96YFTIUmSH3Q6
OzE5XVqcuc5zb%252fY5wy1MZwTnT2pu%252bNMjOjsHjvN
lygTRMzqazPStrN%252f1YzA0oWEWLwkHdhVHeG9sG6cMrf
XNJKHY6fML4o6Nb0SeQm75ET9jAjKelrmqBCNta%252bsKC
9n8jslz%252fo188N4g3BvAJYuzx8J8r%252f1fPFWkPYg%
252bT9Su5KoQ9YpNSj%252bmo0h0aEK%252bofj3f6vCP

nesta tinyURL:

http://tinyurl.com/6

Por quê um sistema existente? Principalmente por ser usuário desse site e achar que o tinyURL é um projeto que poderia ter mais recursos para os usuários, por isso fiz algumas pesquisas e anotei uma lista de coisas que o projeto deverá suprir.

1. O mais importante de todos, permitir que usuários possam escolher um nome significativo para as URL, isso facilita a lembrança da URL, em vez de http://urlcurta.com/4808ebc, é mais fácil lembrar de http://urlcurta.com/mapa-de-casa. Além disso, uma URL com um nome sugestivo, facilita a indexação do site por buscadores como google, yahoo, entre outros. E ainda, com um nome sugestivo, estamos seguindo uma das técnicas de SEO (search engine optimization).

2. Outro item interessante, ás vezes você quer manter em segredo uma URL, mas não guarda no bookmark (favoritos) porque o seu computador é compartilhado com a familia, então porque não permitir que o usuário possa indicar um código de segurança para uma URL? Assim, ele pode salvar a URL sem se preocupar, pois só ele ou quem tiver o código de acesso poderá visualizar aquela URL.

3. Uma lista de URLs, por vezes você quer passar uma lista de URLs para seus contatos do MSN, mas são todas URLs enormes, como a do exemplo do tinyURL, para que o usuário não precise criar várias URLs curtas, o site pode permitir que o usuário simplesmente agrupe várias URLs dentro de uma só (e ele poderá indicar o código de segurança), em vez de lembrar 5 URLs, ele só precisa lembar de uma!

4. Não encontrei nenhum site que tenha um diretório de URLs, e isso pode ser muito interessante, pois facilitaria o trabalho dos buscadores para indexar as páginas, além de ajudar os usuário a divulgar o site. Assim, podemos categorizar as URLs e ainda adicionar tags para cada uma, mais meio para os buscadores indexar as páginas cadastradas. Páginas não categorizadas, sem tags, e principalmente com código de segurança não devem aparecer no diretório.

5. Pré-visualizar a URL para a qual está sendo redirecionado, diferente do tinyURL, onde você deve selecionar a opção, vamos fazer o negócio acontecer por padrão, e quem não quiser, que desabilite, vamos garantir que o usuário foi avisado que a URL pode ser perigosa. Penso que isso pode ser um cookie com 30 dias de duração, depois o usuário cancela o aviso novamente, se for o caso. Uma forma de proteger o usuário.

6. Outro item importante, é um espaço para que usuário possam denunciar URLs mal-intencionadas, sempre vai ter um engraçadinho para usar o sistema de forma errada, para práticas de spamming, esconder vírus, etc. Além disso, mais para frente, pretendo implementar um sistema (talvez um novo projeto) para que no momento de cadastrar uma URL, esse sistema possa analisar o conteudo da URL e bloquear a criação da URL, antes mesmo de acontecer. Tenho algumas idéias para isso, mas preciso estudar um pouco mais o assunto. É um complemento ao item anterior.

7. Para estudar um pouco mais webservices, pretendo também, criar uma área especial onde desenvolvedores de outros sites poderiam utilzar esse sistema para gerar URLs curtinhas sem precisar acessar o site. Como é baseado em XML, sites desenvolvidos em qualquer linguagem poderiam se integrar sem maiores dificuldades.

8. Fidelizar os usuários também é importante, penso que uma forma de fazer isso, é fazendo que algumas funcionalidades só estejam disponiveis quando o usuário estiver logado, por exemplo: gerenciar as URLs cadastradas, poder visualizar o número que visitas que cada URL já recebeu (sacanagem, mas você passa a URL para 5 amigos e no outro dia você olha no site e só tem 3 visitas, alguém não acessou, mas disse que era legal o site hehe).

9. Ainda é uma coisa para pensar como implementar, mas seria legal uma página para acessar via celular, onde o visitante pudesse criar urls curtas pelo celular. (adicionado em 09/jun)

10. Aceito sugestões!
Espero que gostem da idéia e acompanhem o projeto, para discutir-mos o que poderia ser feito, tanto em funcionalidades, como em utilização do Zend Framework.

Um abraço e até o próximo post!

André

ShareThis