A organização do evento começou em agosto de 2015, com a ideia de realizar um evento em parceria com o PHPSP, maior do que os anteriormente organizados, a Locaweb nos procurou para um evento que deveria ser realizado ainda em 2015 na Bienal de São Paulo, um marco turístico da cidade localizado dentro do Parque do Ibirapuera, porém eram poucas as opções de data até o fim daquele ano, muitas delas coincidindo com feriados, o que reduziria a participação do público, após algumas negociações entre PHPSP, Locaweb, e Fundação Bienal ficou decidido que o evento seria realizado no dia 30 de Janeiro.
​
Começou então a curadoria de conteúdo, após diversas conversas online entre os evangelistas do PHPSP ficou decidido fazer um evento focado em temas novos e diferentes e investir fortemente na interatividade do evento, com base nessas diretrizes começamos a selecionar conteúdos e palestrantes dentre aqueles que já estavam na nossa lista e convidar palestrantes que ainda não estavam nessa lista, mas que sabíamos que poderiam agregar conteúdo extremamente relevante para o evento.
​
Enquanto isso a Locaweb corria com a organização do espaço, coffee break, arquitetura do evento e parte técnica, para garantir que o evento ocorresse da melhor forma possível.
​
Com a grade e o tema definidos passamos então a desenvolver a aplicação de interatividade do evento, com base em uma apresentação anterior do Gabriel Couto na PHP Experience utilizando Reveal.js e WebSockets começamos a criar uma aplicação onde os palestrantes pudessem desenvolver seus slides com áreas de interatividade para que fossem acessados pelos participantes durante o evento.
​
Durante esse tempo ainda tivemos alguns imprevistos, com a proximidade do carnaval a CET resolveu bloquear o acesso pelo portão 3 do Parque do Ibirapuera no dia do evento para a passagem dos blocos de rua de São Paulo, isso poderia dificultar bastante o acesso dos palestrantes, então a Locaweb disparou um e-mail para todos os inscritos avisando das alterações e sugerindo rotas alternativas e estacionamentos próximos. Mas novamente um dia antes do evento a CET mudou os horários dos bloqueios e complicou ainda mais as coisas.
​
Não havia mais o que fazer além de torcer para que todos conseguissem de alguma forma chegar ao evento. Então chegou o dia do evento, por conta dos problemas com trânsito e estacionamento os participantes tiveram problemas já esperados de acesso e o evento começou com um pouco de atraso.
​
Na abertura procurei ser o mais sucinto possível para não atrasar ainda mais, junto o Cássio e o Kemel falamos um pouco sobre os eventos já realizados do PHPSP em parceria com a Locaweb, o Cássio falou um pouco de como essa parceria começou e eu agradeci a presença de todos e o apoio da Locaweb, expliquei como funcionaria o aplicativo de interatividade do evento e prosseguimos então para a primeira palestra do dia.

O Marcel Santos abriu as palestras do evento com sua sempre elogiada palestra de Programação Funcional em PHP, um tema que é bastante recorrente nas comunidades de JavaScript por exemplo porem ainda pouco conhecido da comunidade PHP, como sempre foi uma ótima apresentação do Marcel, seguida por algumas dúvidas.

​

Ao final da apresentação do Marcel fizemos sorteios de algumas camisetas e brindes, também usando a aplicação interativa de palestrar, através de um slide especialmente preparado para isso eu pude sortear entre todos aqueles que estavam conectados na aplicação e o nome do vencedor do sorteio era exibido da tela e uma mensagem era exibida no device do sorteado.

​

Enquanto o slide de sorteio era preparado o Gabriel explicou como foi desenvolvida a aplicação de interatividade, quais tecnologias foram utilizadas e como todos poderiam contribuir com ela no Github do PHPSP. E a maior surpresa do evento foi saber que graças a essa aplicação de interatividade o Leonardo, um dos participantes do evento que é deficiente visual pode acompanhar os slides usando seu celular com auxilio de um leitor de tela. Confesso que isso aconteceu totalmente por acaso, mas foi fantástico.
​
Dando continuidade ao evento, e em sua primeira palestra em um evento aberto ao público, o Edson falou um pouco sobre Arquitetura Orientada a Eventos numa apresentação bem descontraída e interativa, no final do evento ele me confessou que estava um pouco nervoso por ser sua primeira palestra, mas em nenhum momento isso transpareceu para o público e a apresentação também foi ótima seguida de mais uma seção de perguntas.

Em seguida o Nickolas iniciou sua apresentação sobre “React além dos Websockets” e demonstrou como fazer uso dessas tecnologias para criar aplicações totalmente dinâmicas e não bloqueantes em PHP terminando com uma demonstração de Robô para automatizar tarefas de mouse e teclado através de uma aplicação para controlar o jogo Tíbia.

Nesse momento subi ao palco novamente para dar mais alguns avisos sobre o almoço, que também foi um pouco complicado pois existem poucas opções de restaurantes e lanchonetes próximas e algumas delas estavam fechadas por conta do fechamento do acesso ao parque. Por isso tivemos mais alguns minutos de atraso no retorno.
​
Retorno esse que aconteceu com a palestra do Ivan sobre Json Web Tokens, tecnologia que promete revolucionar a troca de informações a segurança de aplicações web, o Ivan mostrou como funciona um token, como criar tokens e integrá-los a sua aplicação, e ainda deu exemplos de bibliotecas que estão utilizando essa tecnologia de forma inovadora.

Em seguida o Daniel falou sobre PSR7 e Middlewares, começou explicando como funciona o protocolo HTTP e como todos os frameworks possuíam abstrações diferentes para o protocolo e prossegui mostrando como a PSR7 pode impactar beneficamente na interoperabilidade entre os frameworks através do uso de middlewares.

​
Depois todos os participantes foram bem tratados com um excelente Coffee Break, enquanto isso eu já ajudava a preparar a próxima atração do dia, mantendo o foco de interatividade começou o painel só de mulheres, onde Ariana, Thamara, Diana, Juciellen e Gabriela, essa última direto de Londres, falaram sobre diversos assuntos como Testes de Software, Frameworks e Microframeworks, Diversidade na Tecnologia, Integração Continua e Deploy e PHP7.

Para finalizar as palestras o Diego falou sobre automatização de casas com PHP, mostrou um pouco de Arduíno e como trabalhar com ele, falou um pouco de websockets e finalizou com um show de luzes no palco controladas pela plateia, levando a interatividade ao nível máximo.

​No encerramento mais sorteios, incluindo o Sorteio de um ElePHPant do PHP7, camisetas, mochilas e outros brindes, com todos os evangelistas do PHPSP e a equipe da Locaweb presentes no palco agradecendo a presença de todos os participantes. Mas não terminou por aí, depois do evento muitos participantes se reuniram em um bar próximo para terminar o dia com muita conversa e networking e claro que algumas comidas e bebidas mantendo a tradição dos Pubs do PHPSP.

E para finalizar esse post eu gostaria de agradecer imensamente todos os membros do PHPSP, especialmente o Gabriel, que me ajudou imensamente a fazer com que a aplicação funcionasse sem nenhum problema durante todo o evento, inclusive apagando alguns incêndios durante o desenvolvimento, ao Marcel por ter também contribuído com a aplicação e ter cuidado das redes sociais do PHPSP durante o evento, todos os palestrantes e evangelistas do PHPSP que em nenhum momento negaram ajuda quando essa foi solicitada e em muitas vezes ajudaram em coisas que eu nem mesmo me lembrava que tinham que ser feitas. Ao Cássio, Kemel, Raquel e toda a equipe da Locaweb por mais uma vez fazerem essa parceria incrível entre Locaweb e PHPSP funcionar.
​
O Rafael Dohms, acredito que se referindo à participação em uma conferência, postou o seguinte tweet.
​

Conferences: mentally and psychologically energizing, physically destroying…

— Rafael Dohms (@rdohms) 31 janeiro 2016

Esse tweet reflete também a sensação de participar da organização de um evento desse porte, muitas vezes me senti completamente acabado fisicamente, praticamente virei algumas noites na preparação de algumas coisas e realmente agora preciso de algumas férias, mas essa foi sem dúvida uma das experiências mais recompensadoras de toda a minha vida, espero que todos que estiveram presentes tenham saído com a mesma sensação e que possa ver todo mundo novamente em breve.

Enquanto isso todos podem continuar acompanhando o trabalho do PHPSP nas nossas redes sociais, Facebook, Twitter, Meetup e avaliar as atividades do evento no Joind.in.

O evento conta com desenvolvedores especializados na área. Entre as palestras, estão: “Programação funcional em PHP: saia da zona do conforto”, “Arquitetura orientada a eventos”, “REACT além dos WebSockets”, “Autenticação com Json Web Token (JWT)”, “PSR-7 e os Middlewares”, “Automatizando casas com PHP” e o Painel Seminário Locaweb PHPSP.

No dia do evento, os inscritos devem levar um quilo de alimento não perecível, que serão doados para o Lar Efrata, instituição filantrópica sem fins lucrativos que cuida de crianças e adolescentes sem um lar. As vagas são limitadas e as inscrições gratuitas podem ser feitas via internet.

Organizado pela Locaweb e pela comunidade PHPSP, com patrocínios da Agência ICOMP e da empresa de comércio eletrônico TrayCommerce, o Seminário Locaweb PHPSP está em sua primeira edição e espera receber cerca de 350 participantes interessados no tema.

Serviço: Seminário Locaweb PHPSP
Quando: 30 de janeiro de 2016, das 8h às 18h
Onde: Fundação Bienal de São Paulo – Portão 3, Pavilhão Ciccillo Matarazzo, Parque do Ibirapuera – São Paulo (SP)
Informações: http://eventos.locaweb.com.br/5o-seminario-locaweb-phpsp-sao-paulo/

Sobre a Locaweb:

A Locaweb é líder em Hosting Infrastructure Services no Brasil, segundo a IDC. Com 17 anos de experiência, cerca de 900 funcionários e 260 mil clientes, oferece soluções em Software, Plataforma, Infraestrutura e Marketing, além da unidade Locaweb Soluções Corporativas, que entrega desde simples projetos a escopos totalmente customizados. Com capacidade para mais de 25 mil servidores, de acordo com o relatório Hostmapper, a empresa é líder isolada no mercado de domínios .com.br. Entre 2012 e 2013, adquiriu quatro novas empresas: a Eventials, a Tray, a SuperPay e a All In Mail.

Informações à Imprensa:
NB Press Comunicação
Telefone: (11) 3254-6464
Natália Lippo – natalialippo@nbpress.com
Fernanda Brianezi – fernandabrianezi@nbpress.com

Mas para contar minha historia com PHP eu tenho que voltar um pouco antes disso, em 2001, quando eu ainda cursava a sétima serie do ensino fundamental, tinha uma disciplina chamada Intermátca (Interdisciplinaridade e Informática, eu sei o nome é péssimo) e o ano inteiro da disciplina consistia em escolher um tema de seu interesse e desenvolver uma página na internet (estática mesmo) falando sobre esse tema, depois de pensar um pouco sobre qual tema iria escolher acabei optando por falar sobre Isaac Asimov já que robótica era um tema que me interessava bastante, no final desse ano eu não só entreguei um site funcional (com FrontPages em HTML 3 usando frames) que contava um pouco sobre a história do Asimov e continha uma seção com sua bibliografia principal, como também desenvolvi o trabalho de quase todo o resto da turma (tomara que meus professores da época não leiam isso) mas mais do que me garantir a aprovação na matéria isso me abriu os olhos para um mundo até então desconhecido de desenvolvimento de páginas para web.

No ano seguinte a disciplina se repetiu mas parecia mais do mesmo e eu queria mais que isso, comecei então a desenvolver pequenos sites estáticos sobre conteúdos dos quais eu também gostava e cheguei a publicar alguns deles na época, foi nessa época que tive meu primeiro contato com CSS e Web Semântica, o ensino médio chegou e reduzi um pouco essas atividades até que em 2006 depois de já ter sido aprovado no vestibular para a faculdade de Sistemas de Informação resolvi aprofundar meus conhecimentos nas férias antes das aulas começarem, nessa época os sites dinâmicos estavam tomando conta do mercado de tecnologia e eu queria saber como desenvolver páginas com conteúdo personalizado para o usuário e que armazenavam informações no que mais tarde fui descobrir ser um banco de dados.

Acontece que eu não conseguia fazer isso com HTML e CSS, e Javascript não era nem 1% do que é hoje, então comecei a pesquisar como isso era feito e as duas linguagens que apareceram para mim foram PHP e ASP (Legacy ASP), pesquisei mais um pouco na internet e descobri que o Senac de São Paulo oferecia cursos das duas tecnologias, me inscrevi então nos dois para poder decidir qual delas eu mais gostava na prática, porém o “destino” influenciou minha escolha e o curso de ASP acabou sendo cancelado por falta de alunos, foi então que tive meu primeiro contato com PHP.

Nem dois meses depois comecei a faculdade juntamente com um estágio de desenvolvimento web em um provedor de internet à rádio local, acontece que a maioria dos sistemas desenvolvidos por essa empresa eram feitos em .NET com VBScript fiquei então responsável mais pelo front-end das aplicações que era o que eu dominava um pouco mais, porem como a principal atividade dessa empresa era fornecer conexão a radio para alguns condomínio e empresas da região o desenvolvimento de sistemas acabava ficando em segundo plano e isso me deu bastante tempo para estudar durante o horário de trabalho.

Não cheguei a ficar nem um ano nesse estágio, comecei a fazer alguns cursos de desenvolvimento em um centro de treinamento e a partir de um desses cursos me surgiu a oportunidade de trabalhar como freelancer em um projeto de grande porte em uma indústria de cosméticos em parceria com uma agencia de desenvolvimento, depois que esse projeto freelance acabou ainda desenvolvi mais alguns projetos com essa agencia de desenvolvimento, mas logo em seguida decidi abrir minha própria empresa de desenvolvimento, a Psyco.

Não vou negar que ter controle de todos os passos do desenvolvimento de uma aplicação e poder tratar diretamente com o cliente eram muito bons, mas como a maioria dos projetos eu acabava cuidando sozinho, comecei a sentir falta da evolução que vinha com a troca de conhecimento com outros profissionais foi então que decidi começar a participar mais de eventos e congressos de desenvolvimento, e em um dos primeiros grandes eventos de desenvolvimento grandes que eu fui nessa época, o TDC São Paulo, eu conheci o PHPSP, fui então conversar com o Anderson “Duodraco” Casimiro para saber como eu poderia participar mais da comunidade, ele me falou de alguns eventos que o PHP fazia na época e fiquei de participar dos próximos, mas antes disso no final daquele mesmo dia de TDC fui com alguns dos participantes do evento e membro da comunidade para uma confraternização depois do evento, foi nessa confraternização que acabei conhecendo pessoas como Rogerio, Hussani.

Depois disso comecei a participar dos encontros no iMasters que rolavam na época e dos Pubs organizados pelo PHPSP e conheci ainda mais pessoas ótimas como o William, Diego, Thamara, Ivan e muitos outros e passei a me envolver cada vez mais com a comunidade de desenvolvimento principalmente com o PHPSP e isso passou a ser uma parte muito importante da minha vida. Depois disso já participei de muitos outros eventos, palestrei em alguns e ajudei a organizar alguns outros também, descobri o que realmente é o mundo Open Source e passei a contribuir com ele, me tornei um profissional certificado pela Zend e espero continuar seguindo nesse caminho que só me trouxe coisas boas.

Por isso gostaria de aproveitar e agradecer a todos os que foram citados nesse artigo e muitos outros que não foram mais que fazer parte do PHPSP e das comunidades de desenvolvimento pelo mundo, muitos deles que eu tive oportunidade de conhecer pessoalmente e outros que acompanho pelas redes sociais, Obrigado a todos e que os próximos 20 anos sejam ainda melhores.

E se você ainda não cansou de ler tudo isso e quiser saber também as histórias sobre PHP de outros desenvolvedores aqui segue uma listinha de algumas dessas histórias que foram publicadas hoje:

• Bem Ramsey
• Cal Evans
• Rob Allen
• Michelangelo van Dam
• Matthew Weier o’Phinney
• Anderson “Duodraco” Casmiro
• Erika Heidi
• Rafael Dohms

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.

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.