Refatorando Padrões

Da técnica AJAX, o que sempre noto é que as pessoas a amam de coração ou odeiam até a morte, não há um meio termo.

Os que odeiam, normalmente já odeiam Javascript também, e odeiam ainda mais quando os que amam exageram absurdamente no uso da técnica, conseguem fazer o site ficar inutilizável, uma usabilidade de dar medo, o teclado simplesmente não serve mais. E não me venham falar pra usar o mouse pois usabilidade é para todos os dispositivos. E o motivo principal de usar AJAX (desempenho), foi esquecido a muito tempo.

Dou certa razão para os que odeiam, a usabilidade é item prioritário na construção de um website, de que adianta ser lindo se não conseguimos utilizá-lo. Existem padrões web, utilize-os sempre na medida das possibilidades. Antes perder em semântica do que usabilidade.

Mas vamos lembrar primeiro que AJAX não é um framework, tecnologia, API ou biblioteca. AJAX é uma técnica que pode envolver o uso de várias tecnologias (Javascript, XML, DOM, etc), e pra espanto de vários, foi iniciativa da Microsoft, a própria criou o objeto XMLHttpRequest, responsável pelas requisições assíncronas, embora seja uma técnica que pode ser alcançada usando iFrames também.

Desempenho! Afinal banda de internet é cara, os serviços de hospedagem no Brasil que o digam… AJAX serve para melhorar o desempenho para todos, seja do sobrecarregado servidor ou do usuário que ainda utiliza modem (sem piadas, 53% dos internautas brasileiros ainda utilizam modem). Um bom exemplo de uso da técnica pode ser vista no sistema de creditar do Infoblogs, um simples clique e pronto lá foi o crédito, sem precisar que a página seja renderizada novamente para atualizar uma única tag, simples e ótimo para todos.

Agora um péssimo exemplo é quando temos mega formulários em alguns sites e o submit é uma chamada usando AJAX. Se não utilizar um framework decente, isso dá um trabalho enorme para implementar. E o que ganhamos com isso ? Mais manutenção, o ganho de desempenho é minúsculo. Os vários dados do formulário terão que ser enviados de qualquer forma, todo um processo de parse deve ser feito via javascript e parse de dados é algo que o próprio browser já faz naturalmente ao fazer o submit, ou seja, apenas processando à toa.

Então devemos pesar bem quando utilizar a técnica, pode até ser para algo bonitinho, mas vale mesmo a pena ganhar mais manutenção ? Pense sempre em desempenho e não perca a usabilidade de vista.

Vejo muitos que programam perfeitamente, orientado a objetos, seguindo padrões a risca. Comentam entusiasticamente em fóruns sobre seus novos frameworks, linguagens e bibliotecas, querem é claro, angariar novos adeptos. De fato, boa parte desses projetos são maravilhosos em suas descrições, isso quando há uma descrição…

O ponto onde quero chegar é que na maioria dos projetos que vejo, a documentação é escassa, não há tutoriais ou documentação sequer no código fonte.

Quanto a documentação em código, eu reconheço o que Rod Johnson, criador do Spring, sabiamente afirmou em seu célebre livro Expert One-on-One J2EE Design and Development, um código bem escrito, seguindo padrões claros, sem classes, métodos ou variáveis obscuros, não necessita de documentação, o código fala por si, qualquer programador olha e entende sem medo, mas isso serve somente para quem participa do projeto.

O problema é que ninguém está interessado em olhar dúzias e dúzias de classes para entender como usar. São necessários tutoriais e documentação farta para que consigamos manter alguém usando o que criamos, por melhor que ela seja.

O criador se desespera, óbvio que para muitos é maçante documentar código, mas é necessário, e não é preciso escrever duas vezes, uma em código e outra em documentação pública. São muitas as ferramentas que resolvem o problema. Mas lembre-se que é necessário documentar seguindo padrões, para o pessoal de Java, use JavaDoc, embora limitado/criticado por muitos, é muito fácil de ser utilizado, quantos já não recorreram a documentação do JDK, alguém teria a paciência de ter lido o código ? Eu já tive que ler código várias vezes em muitos frameworks sem documentação, sendo que um mero comentário explicativo na documentação da classe teria resolvido o problema rapidamente.

Eu não sou muito fã da Microsoft, mas tenho que dar o braço a torcer, felizes os usuários do MSDN, quando necessito tirar uma dúvida quanto ao uso de CSS, HTML, ou outras áreas relacionadas, vou direto nele, tudo bem explicado e com ótimos exemplos. A Microsoft pode até não abrir o código fonte de suas ferramentas, mas ela compensa muito bem isso fornecendo aos seus usuários toda a documentação necessária para utilizá-la.

Então na próxima vez que alguém reclamar que seu framework é complicado, para e pense um pouco? “Será que tenho bons tutoriais e documentação ? Será que descrevi de forma concisa o que ele faz ?”. Não espere que o usuário simplesmente baixe e fique tentando adivinhar como usar, não o chame de estúpido, o código do framework/biblioteca é simples para você que criou.

O usuário terá que perder um tempo precioso estudando, e a não ser que seja algo revolucionário, existem alternativas para vários frameworks/bibliotecas. Temos que aprender a cada dia, cada vez mais, não temos tempo a perder tentando adivinhar o que foi codificado. Queremos algo claro e rápido, bem documentado, para finalmente decidir se vale a pena investir tempo.

Não faz muito tempo, surgiu a necessidade de aumentar o desempenho de uma aplicação JEE, e começamos a ver profile daqui, examina relatórios dali, nisso um amigo de projeto, que a pouco tempo havia se enturmado com Rails, teve uma idéia: "Por que não fazemos cache das páginas mais frequentes, podemos criar um pequeno framework, e fazer como o Rails faz", explicando... em Rails basta colocar no controller as páginas que você deseja que sejam "cacheadas". Ex:

Pronto, a primeira chamada à action "noticias" cria o cache, e será usada pelas chamadas subsequentes. Para expirar o cache basta chamar:

Mais detalhes e excelente tutorial no Rails Envy.

Eu gosto muito de criar coisas novas, mas como dito no último post, criar mais um mini-framework para dar manutenção em uma aplicação já não muito pequena... bem, não obrigado. Foi por isso que eu disse: "Cara, dá uma pesquisada, com certeza alguém já fez isso." E pra variar, sim alguém já fez isso.

O excelente e bem conhecido EhCache possui esta funcionalidade e muitas outras.

Este mini tutorial parte do pressuposto que já se tem conhecimento do EhCache e de ServletFilter, para quem não conhece qualquer um dos dois, sem pânico, são muito fáceis de serem utilizados, vale uma pesquisada por tutoriais.

Para facilitar a vida, podem baixar este anexo com a aplicação-exemplo que fiz, basta colocá-lo em seu container web predileto, no meu caso testei no Tomcat, e acessar as URLs de teste:

http://localhost:8080/cache/semcache/teste.jsp

http://localhost:8080/cache/comcache/teste.jsp

O exemplo, mostra a hora atual em milesegundos. A página com cache, após acessada, terá 10 seg de vida.

Para implementar bastou os seguintes passos:

- Baixar e instalar os jars EhCache (ehcache-1.3.0-beta.jar), EhCache Constructors (ehcache-constructs-0.7.3.jar) e Commons-logging (dependência requerida) no diretório lib.

- Incluir no arquivo ehcache.xml as configurações para cache de página, as propriedades falam por si, configurem a gosto:

- Configurar um ServletFilter no web.xml, para a implementação de filtro SimplePageCachingFilter

- Indicar para quais páginas fazer cache a partir do ServletFilter definido acima, dentro do web.xml. No exemplo, tudo que estiver abaixo do diretório "comcache".

Pronto, é somente isso, a página será devidamente cacheada, seguindo as configurações do ehcache.xml.

Caso queira fazer cache de apenas uma parte da página, no caso de quem utiliza jsp:include, basta utilizar a outra implementação PageFragmentCachingFilter

Essa pequena implementação já garantiu um bom desempenho em várias páginas e sem reinventar a roda criando um mini-framework para esta função.

Se alguém souber de outro meio para fazer cache de página em Java, por favor esteja a vontade para comentar, gostaria muito de conhecer outras implementações.