Resumo do Semestre

No início do ano tinha como meta para o blog realizar a publicação de pelo menos um artigo por semana, esse planejamento foi mais do que cumprido, durante o segundo semestre, mas especificamente no meio da série sobre Gerenciamento de Projetos esse número de artigos passou a ser de dois por semana, isso aconteceu em consequência do grande conteúdo referente a gerenciamento de projetos com o qual eu queria trabalhar e graças a aceitação que a série teve com os leitores, estando até hoje entre os artigos mais lidos do blog, com o fim da série, o volume de publicações do blog voltou a ser novamente de 1 artigo por semana, foram 68 artigos publicados ao todo no blog esse ano, fazendo com que a meta tenha sido cumprida.

Além disso no início desse semestre estabeleci com metas, algumas mudanças no blog, incluindo mudanças na plataforma utilizada e mudanças nas áreas de comentários, essas mudanças começaram a ser realizadas mas ainda não foram concluídas, mas em breve essas novidades vão estar presentes no blog.

No que diz respeito ao desenvolvimento do Psyco Content Manager, o sistema de gerenciamento de conteúdo da Psyco, os sistema foi implantado inicialmente em alguns clientes que já o estão utilizando e como retorno dessas implantações foram obtidas muitas sugestões de melhorias para o sistema, essas melhorias estão sendo realizadas em paralelo ao desenvolvimento de novos módulos para o sistema, alguns que já estavam previstos anteriormente e outros que foram incorporados ao longo do semestre.

Planos para o Próximo Semestre

Com relação ao blog o plano para o próximo semestre é de concluir as alterações nas áreas de comentário e realizar a migração total do blog para o Psyco Content Manager (O site da Psyco já está sendo desenvolvido com a plataforma própria e com a mudança do blog deverá haver uma maior integração entre eles).

Os outros planos para o próximo semestre estão mais relacionados ao Psyco Content Manager, no começo desse semestre haviam três linhas de desenvolvimento, uma delas voltada às atualizações do módulo principal do sistema, de gerenciamento de conteúdo e outros duas voltadas para o desenvolvimento de mais dois módulos, com o aumento no número de módulos em desenvolvimento esse semestre mais três linhas de desenvolvimento foram criadas, com isso são agora seis linhas de desenvolvimento do sistema andando em paralelo, o principal plano para esse novo semestre e concluir essas seis linhas de desenvolvimento e com isso apresentar as mudanças e evoluções do modulo de gerenciamento de conteúdo e os novos cinco módulos ainda nesse próximo semestre. Se for levado em consideração que todas essas linhas de desenvolvimento já estão em fase avançada isso não será nada impossível.

Natal, Ano Novo e Ferias

Para concluir esse ano bastante produtivo, quero desejar aos leitores, amigos e clientes um feliz natal e um excelente ano novo, que no ano de 2012 todos os planos possam ser concluídos e todos os desejos alcançados e que ainda sobrem idéias para novos desejos para muitos e muitos anos, pois só se pode seguir em frente com motivação e novos desejos para nos guiar. O Blog entra hoje em recesso de final de ano, mas logo mais estarei de volta com novidades e um pouco mais de Tecnologia, Negócios e o Mundo.

Iniciando uma Requisição HTTP Remota.

Para iniciar uma requisição HTTP remota tudo o que precisa ser feito é abrir uma conexão com o servidor externo através do protocolo HTTP usando para isso a classe Zend_Http da seguinte forma:

$client = new Zend_Http_Client($recipient);

Você ainda poderá passar alguma configurações para essa requisição, como por exemplo limitar o número de redirecionamentos para 0, ou seja, não permitir que o servidor redirecione para outro site ou aplicação, e limitar o tempo de resposta do servidor, para evitar problemas caso o servidor esteja indisponível, essas configurações podem ser feitas da seguinte forma.

$client->setConfig(array(
	'maxredirects' => 0,
	'timeout'      => 30));

Passando Parâmetro para a Requisição.

Além de ajustar as configurações de conexão ainda é possível passar parâmetros para essa requisição, um exemplo dessa utilização e caso seja necessário passar dados pelo método POST, usado frequentemente em formulários, o exemplo a seguir mostra a passagem de alguns dados usando esse método:

$client->setParameterPost(array(
	'search'  => 'Psyco',
	'limit'   => 10,
));

$client->setMethod(Zend_Http_Client::POST);

No exemplo acima estamos passando dois parâmetros através do método POST, o primeiro deles seria um termo de busca e o segundo um limite de respostas que seriam exibidas, esses dados poderiam ser passados para um mecanismo de busca para obter seus resultados.

Obtendo a Reposta

Depois de realizar todas as configurações e passar os parâmetros necessários é hora de receber as resposta desse servidor, a instrução a seguir demonstra como isso deve ser feito:

$response = $client->request();

Essa instrução irá obter a resposta completa do servidor, o que incluíra o cabeçalho do arquivo e da requisição assim como todo o conteúdo da página, você pode filtrar essa requisição e obter somente o cabeçalho ou somente o conteúdo através das instruções abaixo:

$response = $response->getHeader(); //Recebe o cabeçalho
$response = $response->getBody(); //Recebe o conteúdo

Conclusão

Existem diversas formas de comunicação entre diferentes sites ou aplicações, anteriormente falei um pouco sobre as requisições XML-RPC, essa foi a vez de exemplificar um pouco conexões externas utilizando o próprio protocolo HTTP, cada cenário poderá exigir uma solução diferente, cabe ao programador da aplicação definir qual das soluções melhor se adapta as necessidades.

Incorporando Áudio com HTML 5

Incorporar áudio com HTML5 é muito simples, tudo o que precisa ser feito é inserir o seguinte código na sua marcação:

<audio controls="controls">
	<source src="audio.ogg" type="audio/ogg" />
	<source src="audio.mp3" type="audio/mp3" />
	Seu Navegador Não Suporta Áudio em HTML5
</audio>

No código acima vemos a tag <audio> que indica a presença de um elemento de áudio na página, nesse caso a tag só contém um atributo controls, que quando incluído instrui o navegador a exibir os controlers desse vídeo, caso esse atributo seja omitido os controles não serão mostrados, além disso essa tag ainda pode receber outros atributos que não estão presentes nesse exemplo, são eles, “autoplay”, que caso incluído fará com que o áudio toque automaticamente com o carregamento da página (use com moderação), “loop” que indicará que ao final do áudio ele deve ser tocado novamente, e “preload” que indica que o arquivo de áudio deve ser carregado (apenas carregado, não tocado) juntamente com a página.

Dentro dessa tag <audio> existem duas tags <source>aonde são informados os caminhos para dois arquivos de áudio, um em .mp3 e um e .ogg, isso é necessário pois alguns navegadores só possuem suporte a um desses tipos de áudio, então para que sua aplicação funcione corretamente nos navegadore modernos é fundamental que você forneça o arquivo em pelo menos esses dois formados, cada um deles contém também o atributo type que indica o mime type desse arquivo.

Por fim, um texto informativo que será exibido somente caso o navegador não possui suporte a tag <audio> do HTML5 é utilizado para informar o visitante dessa limitação do seu navegador.

Incorporando Vídeo com HTML5

Incorporar vídeos em HTMl5 é bastante similar à incorporação de áudio, abaixo um exemplo de código para inserção de vídeo que será dvidamente explicado a seguir:

<video width="400" height="300" controls="controls">
	<source src="video.mp4" type="video/mp4" />
	<source src="video.ogg" type="video/ogg" />
	Seu Navegador Não Suporta Vídeo em HTML5
</video>

A diferença básica entre aúdio e vídeo, e que além dos atributos explicados anteriormente o vídeo deve conter os atributos que determinam a largura e a altura desse componente de vídeo (atributos width e height respectivamente), além disso existem dois outros atributos opcionais que podem ser utilizados, o atributo “poster” que deve receber como valor o endereço de uma imagem que será usada com demonstração do vídeo antes de seu início e o atributo “muted” que caso seja usado fará com que o vídeo toque sem o seu áudio.

Conclusão

A inclusão de áudio e vídeo em HTML5 é bastante simples, porém existem usuários que ainda utilizam navegadores sem suporte a essa tecnologia, por isso é sempre bom fornecer uma alternativa a utilização de HTML5 caso o áudio ou vídeo seja de muita importância para o conteúdo da página, com o tempo e a evolução dos navegadores será possível abondonar as tecnicas antigas e explorar ao máximo as capacidades da nova tecnologia.

Introdução sobre Semântica

A versão 5 da linguagem HTML tem grandes melhorias no que diz respeito a semântica de uso das tags, mas antes de explicar cada uma dessas tags é preciso saber melhor o que de fato é semântica, a semântica aplicada a marcação de páginas HTML é a correta relação entre as tags existentes na linguagem e o conteúdo inserido nelas, ou seja, utilizar semântica corretamente no HTML é marcar um parágrafo com a tag <p> e um link com a tag <a>, porém, esses são exemplos mais óbvios de semântica, a versão 5 da linguagem HTML vem resolver o problema da ausência de semântica da tag <div>, essa tag por natureza é ausente de significado, e seu objetivo é apenas demarcar uma divisão na página, na maioria das vezes apenas por critérios de apresentação.

As novas tags de conteúdo da linguagem tem como objetivo incorporar significado a algumas das áreas mais comuns de uma página HTML, dessa forma são criadas as tags <header>, <section>, <article>, <nav>, <aside> e <footer> das quais vou tratar abaixo.

As Novas Tags

A tag <header> é responsável por marcar a porção do código que se refere ao cabeçalho da página ou seção, esse cabeçalho pode conter por exemplo o titulo do site, uma imagem de cabeçalho e até mesmo um menu principal delimitado pela tag <nav> tratada abaixo. Da mesma forma a tag <footer> é responsável por marcar o rodapé do mesma página ou seção, podendo conter os mesmo elementos da tag anterior.

A tag <section> delimita uma seção do site ou uma seção do site ou do conteúdo, dependendo de onde essa tag está presente na hierarquia do código, delimitados por essa tag podem estar os títulos do conteúdo ou da seção do site. Já tag <article> pode ser literalmente traduzida para artigo, e é dentro dessa tag que deve estar o conteúdo de fato do site ou aplicação. A tag <aside> representaria então o conteúdo relacionado ao conteúdo principal do site, porém, que tem um grau de importância menor que o conteúdo principal delimitado pela tag <article>. Além disso pode representar algum conteúdo relacionado ao uma seção do site e portanto ser utilizado juntamente com a tag <section>.

Por fim tag <nav> é responsável pela navegação do site, portanto é recomendável que os menus do site estejam delimitados pela mesma.

Estrutura dos Elementos na Página

Esse é o principal ponto que desejo tratar nesse artigo, não existe um consenso nem uma regra explicita sobre a estruturação dos elementos na página, o que permite algumas interpretações de significados diferentes para cada um das tags de acordo com a hierarquia dos elementos no site, por exemplo, uma tag <header> ou <footer> um nível imediatamente abaixo da tag <body> representaria o cabeçalho ou rodapé da página, porém, caso essas mesma tags fossem utilizadas dentro de uma tag <section> elas passariam a representar o cabeçalho e o rodapé dessa seção individualmente, dessa forma uma página inteira poderia conter vários cabeçalhos e rodapés, cada um deles se referindo a seções distintas da página.

Da mesa forma isso pode acontecer com a tag <nav>, que caso inserida um nível diretamente abaixo da tag <body> ou dentro da tag <header> ou <footer> da página, representaria o menu de navegação principal do site, a mesma tag inserida dentro da tag <section> poderia representar uma navegação secundária ou específica para aquela seção.

Agora o ponto que mais permite diferentes utilizações das tags é aquele que se refere ao relacionamento entre as tags <section>, <article> e <aside>. Para começar as tags <section> e <article> poderia ser aninhadas infinitamente, nesse caso uma <section> imediatamente após a declaração de <body> poderia representar uma seção do site, que por sua vez poderia delimitar uma tag <article> que delimitaria uma nova tag <section> representando uma seção específica do conteúdo e não mais da página. Além disso a tag <section> poderia ser diretamente aninhada representando uma seção principal e outras sub-se

Realizando Conexão com um Servidor XML-RPC

Antes de se conectar a um servidor é preciso saber se esse servidor suporta o protocolo XML-RPC, se esse servidor realmente suportar o protocolo muito provavelmente haverá uma documentação da interface de conexão com esse servidor, você irá precisar dela para saber os nomes dos métodos que poderá chamar para realizar as consultas ou enviar informações.

Como exemplo vou assumir que está sendo feita uma conexão com um servidor, que suporta o protocolo XML-RPC e que está localizado no endereço “http://servidor.xmlrpc.com/xmlrpc.php”, e que implementa apenas um método “toEnglish” da classe “translate” responsável por receber palavras ou frases em português e retornar sua tradução em inglês.

Para se conectar a esse servidor tudo que precisa ser feito é o seguinte:

$client = new Zend_XmlRpc_Client('http://servidor.xmlrpc.com/xmlrpc.php');

Essa instrução está criando uma instância da classe Zend_XmlRpc_Client, passando como parâmetro o endereço do servidor e armazenando essa instância na variável $client

Realizando Chamadas aos Métodos

Para chamar o método previamente descrito tudo o que precisa ser feito é o seguinte:

$result = $client->call('translate.toEnglish', array('Olá Mundo'));
echo $result; //Hello World

Está sendo chamado o método call da instância de classe armazenada anteriormente na variável $client passando como primeiro parâmetro o nome da classe e método a serem chamados separados por “.” e em seguida um array com os parâmetros requisitados por esse método, nesse exemplo apenas a frase em português que deve ser traduzida, caso o método do servidor tenha sido corretamente implementado ele deverá retornar a String “Hello World”.

Verificando Erros e Faltas

Quando estamos trabalhando com conexões com servidores diferentes muitos fatores podem ocasionar falhar nessa comunicação e muitos deles não estão sob o controle do desenvolvedor, nesse caso tudo o que se pode fazer é verificar se algum erro ocorreu e informar essa falha, isso pode ser feito através de um bloco try-catch da seguinte forma:

try{
	echo $client->call('translate.toEnglish', array('Olá Mundo'));
}catch (Zend_XmlRpc_Client_FaultException $e) {
	echo 'XmlRpc Fault ['.$e->getCode().']: '.$e->getMessage();
}catch (Zend_XmlRpc_Client_HttpException $e) {
	echo 'Erro de HTTP ['.$e->getCode().']: '.$e->getMessage();
}

Nesse caso a requisição XmlRpc está inserida dentro de um bloco try-catch, caso a mesma seja bem sucedida será impresso na tela a tradução da String enviada como parâmetro, caso contrário existem duas possibilidades de erros, a primeira quando a conexão foi realizada com sucesso mas o servidor remoto retornou uma falta, isso pode acontecer caso a string enviada tenha algum caractere inválido ou caso alguma verificação do servidor não tenha sido bem sucedida, nesse caso é impresso na tela o código e mensagem de erro retornados pelo servidor.

Outra possibilidade é que ocorra uma falha na comunicação com o servidor, o servidor pode estar fora do ar temporariamente ou não ser encontrado, nesse caso a classe Zend_XmlRpc retorna um erro de HTTP, esse erro é impresso na tela juntamente com seu código da mesma forma que o anterior. Dessa forma é possível controlar melhor a comunicação entre as duas aplicações.

Conclusão

Com Zend_XmlRpc a comunicação entre duas aplicações se torna muita mais fácil do que caso fosse feita manualmente, com isso é possível acessar API públicas ou proprietárias que forneçam suporte ao esse protocolo e melhorar significamente a sua aplicação.

Dessa forma o artigo que deveria ser publicado hoje (terça-feira), será publicado amanhã (quarta-feira) dando início assim a esse novo ciclo de publicações. Além disso, como de costume, o espaço para comentários do blog está sempre aberto para sugestões de novas pautas, ou de mudanças na periodicidade do blog, além de qualquer outros assunto pertinente aos temas abordados nesse blog. Espero que continuem lendo e comentando os artigos aqui publicados e assim que tiver mais novidades com relação ao blog volto a informar.

Fatores Ambientais da Empresa

O próprio nome desse item já serve para passar uma idéia básico sobre ao que ele se referem, os fatores ambientais da empresa são o grupo de conhecimento, experiências e procedimentos que ambientam tanto internamente como externamente a empresa executora do projeto ou qualquer outra empresa interessada no projeto.

Esses Fatores Ambientais podem ser tangíveis, como, por exemplo, os equipamentos que a empresa possui e quem podem ser usados no decorrer de um ou mais processos, as instalações da empresa que poderão ser usadas para abrigar a equipe executora do projeto ou até mesmo para armazenar os equipamentos próprios e os obtidos de terceiros ou os recursos humanos de cada uma das empresas envolvidas.

Os mesmos também podem ser intangíveis, como a cultura da empresa as padronizações de processos internas ou de mercado, o ambiente político, financeiro, econômico e social no qual estão inseridas as empresas e os projetos, as normas e regulamentações governamentais ou de setor ou até mesmo o relacionamento anterior entre as empresas interessadas no projeto.

Por fim os fatores ambientais da empresa podem ainda ser digitais como sistemas informatizados para gerenciamento do projeto como um todo ou de partes do mesmo ou como canais de comunicação estabelecidos pelas organizações interessadas no projeto.

Ativos de Processos Organizacionais

São as informações e conhecimentos obtidos durante o desenvolvimento do próprio projeto ou de outros projetos, simultâneos ou anteriores, esses estão mais relacionados a conhecimentos técnicos relativos a determinadas atividades de um projeto, resultados de experiências com diferentes procedimentos para uma mesma atividade ou atividade semelhante, bases de informações obtidas de terceiros e/ou alimentadas com informações próprias e procedimentos padronizados para realização de algum tipo de tarefa. Pela sua própria natureza ser relacionada a conhecimento e informação são em sua maioria intangíveis apesar de também poder incluir arquivos referentes ao projeto ou até mesmo protótipos ou diagramas que podem ser considerados mais tangíveis.

Diferentemente dos Fatores Ambientais da Empresa que são realmente utilizados e até mesmo consumidos durante o ciclo de vida de um projeto os Ativos de Processos Organizacionais são mais úteis para auxiliar no desenvolvimento de uma atividade dentro do projeto guiando seus procedimentos do que para serem usados durante as essas atividades.

Conclusão

Tanto os Fatores Ambientais da Empresa quanto os Ativos de Processos Organizacionais podem ser extremamente úteis para o desenvolvimento do projeto e para reduzir as chances de insucesso dos mesmo, porém vão sendo adquiridos ao longo do processo de crescimento e aprimoramento da empresa, além disso muitos desses Fatores Ambientais ou Ativos de Processos Organizacionais podem ser muito úteis para uma empresa mas não se adequar a realidade de uma outra empresa, por isso se sua empresa está começando a trabalhar com projetos agora ou é realmente uma empresa nova saiba que ao longo do processo de crescimento de sua empresa os mesmos serão formados aos poucos, e tudo que você pode fazer para auxiliar nesse processo e aprender o máximo que puder tanto com os acertos quanto com os erros de sua empresa, além disso é sempre importante documentar todos os acontecimentos dos projetos, pois essas informações podem parecer inúteis na início, mas poderão ser muito úteis no futuro.

A Classe Zend_Auth

A classe Zend_Auth do Zend Framework é responsável por cuidar de todo o processo de autenticação e armazenamento da seção de login do usuário, deixando muito mais simples o trabalho de verificação das credenciais de acesso e permitindo a utilização de diversos modo de verificação, incluindo verificação de identidade através do banco de dados, através do protocolo HTTP e até mesmo através de serviços como OpenID. Além disso ela pode ser extendida para realizar a verificação por qualquer outro modo que não esteja disponível nativamente. Nesse artigo apenas o método de autenticação através do banco de dados será apresentado, mas você pode conferir a Documentação Oficial da Classe Zend_Auth caso precise realizar a autenticação através de outro método.

Autenticação Através de Banco de Dados

Tabela de Usuários

Para realizar a autenticação de usuário através do banco de dados é preciso ter uma tabela nesse banco com pelo menos duas colunas, o login e a senha, para critério de exemplo nesse artigo vou adicionar também o nome completo do usuário, seu e-mail, além disso o campo de senha será criptografado usando MD5 (lembrando que o uso de Md5 para armazenar senhas não é recomendado pois é um algorítimo com grande facilidade de quebra, nesse caso usarei apenas como exemplo). O diagrama ao lado ilustra o banco de dados que deverá ser criado para esse exemplo e abaixo transcrevo o código SQL desse banco:

CREATE TABLE `User` (
	id    int(11) NOT NULL AUTO_INCREMENT,
	nome  varchar(255) NOT NULL,
	mail  varchar(255) NOT NULL,
	login varchar(255) NOT NULL,
	pass  varchar(255) NOT NULL,
	PRIMARY KEY (id)
);

O Formulário

Para criar uma ferramenta de login precisamos criar um formulário por onde o usuário irá informar seus dados para que esses sejam verificados.

<?php

class Form_Login extends Zend_Form
{
	public function init()
	{
		$login = new Zend_Form_Element_Text('login');
		$login->setLabel('Login do Usuario')
			->setRequired(true)
			->addFilter('StripTags')
			->addFilter('StringTrim');

		$senha = new Zend_Form_Element_Password('senha');
		$senha->setLabel('Senha do Usuario')
			->setRequired(true)
			->addFilter('StripTags')
			->addFilter('StringTrim');

		$submit = new Zend_Form_Element_Submit('Entrar');
		$this->addElements(array($login, $senha, $submit));
	}
}

O formulário acima contem apenas dois campos, o campo de login e o campo de senha, além é claro do botão que enviará esse formulário para que seus dados sejam processados, as informações sobre método de envio (GET ou POST) foram omitidas, mas é sempre bom lembrar que é altamente recomendável passar dados de login apenas por POST e nunca por GET já que no segundo caso eles ficam visíveis na URL.

O Controller

Praticamente toda a verificação de login nesse exemplo será realizada no Controller, por isso essa parte necessita de um pouco mais de atenção, abaixo segue o código desse controller que será devidamente explicado abaixo.

public function loginAction(){
	if(Zend_Auth::getInstance()->hasIdentity()){
		$this->_redirect('index');
	}else{
		$this->view->form = new Form_Login();

		if($this->getRequest()->isPost() and $this->view->form->isValid($_POST)){
			$values = $this->view->form->getValues();

			$dbAdapter = Zend_Db_Table::getDefaultAdapter();
			$adapter = new Zend_Auth_Adapter_DbTable($dbAdapter);

			$adapter->setTableName('User')
				->setIdentityColumn('login')
				->setCredentialColumn('pass')
				->setIdentity($values['usuario'])
				->setCredential($values['senha'])
				->setCredentialTreatment('MD5(?)');;

			$auth = Zend_Auth::getInstance();
			$result = $auth->authenticate($adapter);

			if ($result->isValid()) {
				$this->_redirect('index');
			}else{
				$this->view->form->setDescription('Usuário ou Senha Inválidos');
			}
		}
	}
}

Uma Action de Login (loginAction) está sendo criada e logo no início dessa Action está sendo chamado um método estático da classe Zend_Auth para verificar se o usuário já está logado, caso ele já esteja ele é direcionado para a página inicial, caso não esteja o formulário criado anteriormente é instanciado e armazenado na variável $this->view->form, ou seja está sendo armazenado em uma variável e passado a visão ao mesmo tempo.

Logo em seguida verificamos se existe uma requisição POST a essa ação e caso exista se o valores passados por essa requisição são válidos de acordo com os parâmetros de validação do formulário, nesse ponto cabe uma observação, caso a requisição não seja do tipo POST ou os valores não forem válidos o formulário será exibido na tela, ou seja, se o visitante ainda não envio nenhum dado para o formulário ou se esses dados estão errados (apenas do ponto de vista de validação de dados, não de login) ele será encaminhado ao formulário para enviar essas informações ou corrigir as informadas anteriormente.

Caso a requisição seja do tipo POST e os valores válidos chegou a hora de verificar se as credenciais estão corretas. A primeira coisa a ser feita é requisitar o adaptador padrão do banco de dados através do método Zend_Db_Table::getDefaultAdapter() e armazená-lo em uma variável, já que vamos precisar dele mais tarde, caso não exista um adaptador padrão previamente configurado será necessário iniciar uma conexão ao banco de dados. Em seguida é criada uma instancia da classe Zend_Auth_Adapter_DbTable passando como parâmetro o adaptador do banco citado anteriormente, e essa instância é armazenada em uma variável.

O próximo passo e passar as informações sobre os dados que serão usados por essa classe através dos métodos chamados logo em seguida. O método setTableName() recebe o nome da tabela de usuários no banco de dados, o método setIdentityColumn() recebe o nome da coluna do banco de dados onde está armazenada a informação de nome de usuário, setCredentialColumm por sua vez recebe o nome da coluna onde está armazenada a senha, os métodos setIdentity e setCredential recebem respectivamente os valores de login e senha passados pelo usuário e por fim o método setCredentialTreatment() recebe a informação sobre o tratamento que será fornecido a senha, nesse caso estamos utilizando a função md5() para criptografar essa senha.

Por fim requisitamos a instância da classe Zend_Auth e chamamos o método authenticate passando como parâmetro a instancia da classe Zend_Auth_Adapter_DbTable já com as informações armazenadas, se o retorno desse método for TRUE redirecionamos o usuário a página inicial se for FALSE incluimos uma descrição ao formulário com as informações de que o login e senha estão incorretos e enviamos o visitante de volta ao formulário para que ele preencha corretamente as informações.

A View

A View nesse caso só tem mesmo que exibir o formulário da seguinte fora:

<h2>Acesso Restrito a Usuários Cadastrados</h2>
<?php echo $this->form; ?>

Armazenando Informações na Seção de Login

Através do método apresentado anteriormente foi possível verificar as credenciais do usuário que estava realizando o login e criar a seção de login do mesmo, porém nessa seção o único dado que foi armazenado foi o nome do usuário, porém as vezes é preciso que mais dados que estejam disponíveis na tabela do banco de dados também sejam armazenados, para isso basta realizar apenas uma pequena alteração no controller que ficará da seguinte forma:

public function loginAction(){
	if(Zend_Auth::getInstance()->hasIdentity()){
		$this->_redirect('index');
	}else{
		$this->view->form = new Form_Login();

		if($this->getRequest()->isPost() and $this->view->form->isValid($_POST)){
			$values = $this->view->form->getValues();

			$dbAdapter = Zend_Db_Table::getDefaultAdapter();
			$adapter = new Zend_Auth_Adapter_DbTable($dbAdapter);

			$adapter->setTableName('User')
				->setIdentityColumn('login')
				->setCredentialColumn('pass')
				->setIdentity($values['usuario'])
				->setCredential($values['senha'])
				->setCredentialTreatment('MD5(?)');;

			$auth = Zend_Auth::getInstance();
			$result = $auth->authenticate($adapter);

			if ($result->isValid()) {
				$storage = $auth->getStorage();
				$storage->write($adapter->getResultRowObject(null,'pass'));

				$this->_redirect('index');
			}else{
				$this->view->form->setDescription('Usuário ou Senha Inválidos');
			}
		}
	}
}

Logo antes de redirecionar o usuário para a página inicial foi chamado o método getStorage() da classe Zend_Auth e em seguida chamado o método write que recebe como parâmetro o retorno do método getResultRowObjet() que por sua vez pode receber como primeiro parâmetro uma lista de colunas do banco de dados que serão armazenadas (nesse caso foi passado null, que fará com que todas as colunas sejam armazenadas) e como segundo parâmetro uma lista das colunas que não serão armazenadas (nesse caso passamos o nome da coluna que contem a senha), ou seja, todas as colunas exceto a que contém a senha serão armazenadas, depois de ter realizado esse processo basta realizar o seguinte procedimento para exibir as informações da seção de login:

echo Zend_Auth::getInstance()->getIdentity(); //Retorna o Login do Usuário mesmo que um Storage não tenha sido criado
echo Zend_Auth::getInstance()->getIdentity()->nome; //Retorna o Nome do Usuário
echo Zend_Auth::getInstance()->getIdentity()->email; //Retorna o E-mail do Usuário

Conclusão

Através da classe apresentada nesse artigo é possível realizar de forma fácil e segura a autenticação do usuário através de diversos meios, aqui apenas um desses meios foi mostrado mas tenha certeza de que com pouca mudança no que foi apresentado é possível se adaptar a qualquer que seja a sua necessidade.

Paginadores no Zend Framework

O Zend Framework possui uma classe de paginação própria, que facilita muito esse trabalho e ainda possibilita um excelente controle do modo como esse paginador será exibido em página, a classe Zend_Paginator permite ainda que vários tipos de dados sejam paginados, os tipos mais comuns são dados contidos em um array e dados provenientes de um banco de dados, nesse artigo iremos abordar apenas o último desses tipos, mas a implementação em cada um deles é bastante semelhante.

Paginando Resultados do Banco de Dados

Para realizar a paginação de dados provenientes de um banco de dados obviamente é preciso ter um banco de dados, e pelo menos alguns dados inseridos nele, não vou entrar no mérito de criação desse banco de dados, pois muitos artigos anteriores já usaram diferentes bancos de dados com diferentes informações e o processo de criação de cada um desses bancos já foi detalhado anteriormente, nesse exemplo vou apenas assumir que existe um banco de dados, cuja conexão já está devidamente configurada no Zend Framework, com pelo menos uma tabela de usuários cujo Model também já foi criado.

Controller

O Paginador de banco de dados do Zend_Framework recebe como parâmetro um conjunto de dados provenientes do banco (rowset) e a partir desse conjunto de dados exibe apenas os resultados definidos pela configuração desse paginador, o código a seguir ilustra a parte dessa ação que é realizada no Controller:

public function indexAction(){
	$pagina = $this->_getParam('pagina', 1);

	$userModel = new User();
	$rowsetUser = $userModel->fetchAll();

	$paginador = Zend_Paginator::factory($rowsetUser);
	$paginador->setItemCountPerPage(20);
	$paginador->setPageRange(9);
	$paginador->setCurrentPageNumber($pagina);

	$this->view->paginador = $paginador;
}

Nesse exemplo todos os registros da tabela de usuário estão sendo buscados pelo método fetchAll() do Model de Usuários ($userModel) e então esses dados estão sendo passados para o método estático factory() da classe Zend_Paginator, esse método irá interpretar qual o tipo de dados está sendo passado para o paginador e realizar as ações necessárias para o tipo em questão.

Em seguida são feitas algumas configurações no paginador, a primeira delas e configurar o número máximo de itens por página para 20, seguido do número de páginas que será exibido nos controles de página e por último informando ao paginador qual página deverá ser exibida, a variável $pagina usada nesse caso armazena o número de página que está sendo passado pela URL e caso isso não tenha ocorrido assume que o número da página é 1 (Linha 1 do Código). Por último o paginador e passado para a view na variável $this->view->paginador.

Partial View

Depois de criar as ações no seu controller é preciso criar uma a estrutura dos controles de paginação, o código abaixo é um exemplo desse tipo de estrutura, é uma alteração do exemplo contido na documentação oficial do framework traduzido para o português:

<?php if ($this->pageCount): ?>
	<div>
		<!-- Controle de Página Anterior -->
		<?php if (isset($this->previous)): ?>
			<a href="<?php echo $this->url(array('pagina' => $this->previous)); ?>">&lt; Anterior</a> |
		<?php else: ?>
			<span>&lt; Anterior</span> |
		<?php endif; ?>

		<!-- Controle Numérico de Página -->
		<?php foreach ($this->pagesInRange as $page): ?>
			<?php if ($page != $this->current): ?>
				<a href="<?php echo $this->url(array('pagina' => $page)); ?>"><?php echo $page; ?></a> |
			<?php else: ?>
				<?php echo $page; ?> |
			<?php endif; ?>
		<?php endforeach; ?>

		<!-- Controle de Próxima Página -->
		<?php if (isset($this->next)): ?>
			<a href="<?php echo $this->url(array('pagina' => $this->next)); ?>">Próxima &gt;</a>
		<?php else: ?>
			<span>Próxima &gt;</span>
		<?php endif; ?>
	</div>
<?php endif; ?>

Esse código deve ser inserido dentro de um arquivo .phtml nesse exemplo vou assumir que esse arquivo está dentro do diretório views/scripts/layout/paginador.phtml mas você pode armazená-lo no lugar que achar melhor, o código acima também é apenas um exemplo de estrutura possível que pode ser alterado para atender as necessidades específicas de cada aplicação.

Action View

No arquivo de view da Action em questão tudo que precisa ser feito é o seguinte:

<?php if (count($this->paginador)): ?>
	<ul>
		<?php foreach ($this->paginador as $user): ?>
			<li><?php echo $user->name; ?></li>
		<?php endforeach; ?>
	</ul>
<?php endif; ?>
<?php echo $this->paginationControl($this->paginador, 'Sliding', 'layout/paginador.phtml'); ?>

Como é possível ver o dados estão sendo exibidos normalmente como se viessem diretamente do banco de dados, a única diferença é que ao final está sendo incluída a instrução para exibir o paginador, o método paginationControl() recebe três parâmetros, o primeiro deles é a instância do paginador que está sendo utilizado, o segundo é o estilo do paginador, para uma lista completa dos estilos disponível você pode acessar a Documentação da Classe Zend_Paginator, e o último parâmetro e o caminho para o arquivo com a estrutura dos controles que foi criado anteriormente.

Para simplificar ainda mais esse processo você pode configurar os padrões desse paginador incluindo no seu arquivo de Bootstrap a seguinte instrução:

public function _initPaginator(){
	Zend_Paginator::setDefaultScrollingStyle('Sliding');
	Zend_View_Helper_PaginationControl::setDefaultViewPartial('layout/paginador.phtml');
}

Feito isso você pode alterar a chamada para os controles de paginação (última linha do código da view Action no início do tópico) para apenas a seguinte instrução:

<?php echo $this->paginador; ?>

Conclusão

Com Zend_Paginator e alguns passos simples é possível melhorar significativamente a experiência do usuário na página e ainda reduzir o tempo de carregamento da mesma e o consumo de trafego do servidor de hospedagem.

Baixando os Arquivos com as Traduções

Os arquivos com as traduções do Zend Framework estão disponíveis somente com a versão completa do framework que pode ser baixada no Site Oficial, esses arquivos não estão disponíveis nem na versão mínima do framework, nem mesmo são importados para o projeto quando se realiza a criação da estrutura de diretórios a partir do Zend_Tool ou Zend Studio, por isso é fundamental que o download da biblioteca completa seja realizado. Após realizar esses download descompacte os arquivos e  copie a pasta “resources” que vem junto com o framework para a raiz do diretório do seu projeto.

Configurando o Bootstrap

Basicamente tudo que é preciso fazer para traduzir as mensagens de erro é configurar o seu arquivo de Bootstrap para incluir a linguagem desejada no tradutor padrão da seguinte forma:

public function _initTranslate() {
	$translator = new Zend_Translate ( array ('adapter' => 'array', 'content' => '../resources/languages', 'locale' => 'pt_BR', 'scan' => Zend_Translate::LOCALE_DIRECTORY ) );
	Zend_Validate_Abstract::setDefaultTranslator ( $translator );
}

Tudo que está sendo feito e criar uma instância da classe Zend_Translate e passar um array com os parâmetros de tipo de tradução, caminho para os arquivos de tradução e linguagem desejada, em seguida chamar o método estático setDefaultTranslator() da classe Zend_Validate_Abstract, passando a instância da classe Zend_Translate criada anteriormente.

Traduzindo Mensagens de Seus Próprios Validadores

Se você mesmo criou um validador personalizado e deseja que esse validador também esteja disponível em mais de uma linguagem, o processo é igualmente simples, deixa a mensagem de validação do corpo da sua classe de validação em inglês, assim esse validador seguirá o padrão do Zend Framework, em seguida insira mais um item no array cuja chave deve ser a sua mensagem de validação personalizada e o valor dessa variável a tradução para a linguagem desejada, como no exemplo a seguir:

"My Personal Message" => "Minha Mensagem Personalizada",
"'%value%' is not a valid CEP" => "'%value%' não é um CEP válido",

Se você usou termos coringa na sua mensagem de erro, como ‘%value%’, por exemplo, você também pode incluir esses valores coringa na sua mensagem de erro, como no segundo exemplo acima.

Conclusão

Com isso você pode deixar as mensagens da sua aplicação na mesma linguagem do restante da aplicação sem ter que alterar todas as classes de validação do framework.