Outra noite sem dormir

Agora são 8:20 da manhão e, enfim, isso coloca eu em outra noite sem dormir. Mas daqui a pouco estou indo.
Hoje terminei de olhar os links que eu começei a olhar 3 dias atrás (eu adoro o Control-Click no Firefox que vai abrindo abas após abas e a gente não "consegue" fechá-lo sem anter ler tudo que elas dizem - olha que elas têm mais links...).
Bem, olhei coisas como o http://www.thinkfree.com, que permite criar documentos do Office Online. Muito legal mesmo, com recursos inimagináveis antes do Ajax e dos Applets Java. Os caras conseguiram imitar o pacote Office grandiosamente. Claro, precisamos uma boa conexão de Internet, mas isso não é coisa difícil hoje. Vale a pena. Olhei alguns sites sobre CSS, como o http://cssbeauty.com, que tem boas dicas sobre CSS (pra gente tirar idéias e copiar mesmo) e daí acabei indo pro Emule (normal) baixar alguns livros "for dummies" pra mim.
Depois, passei pelo last.fm, e criei uma conta lá pra ouvir uns bons countries. Site bom, com muita informação de ranking de músicas, rádios online e bookmarks. Gostei. Aproveitei pra baixar uns livros sobre Ajax e não me contive, acabei brincando com o GWT novamente. Embora um erro "panga" no compilador dele me estressou um pouco, uma olhada no fórum me resolveu o problema. Claro, versão beta, mas com um fórum ativo as coisas se resolvem logo. Depois instalei o Google Notebook e a taskbar do Google, cuja qual tem de mais interessante o recurso pra ativar o Gmail como software padrão para envio (quando se clica em links de email).
Fui para página personalizada do meu Google e adicionei algumas coisas sobre Java, Eclise, J2EE, Ajax, tecnologia, Nasa, Ciência, Filmes e coisas do gênero. Um link do MyEclipse com suporte para o Matisse me chamou a atenção e acabei indo para ele. Baixei a versão development do MyEclipse (adoro essas versões, parece que a gente é desbravador...) pra testar o port do Matisse nele. Mas isso me levou para updates no meu Eclipse (mais precisamente para uma versão > 3.2RC4) e no final das contas eu já estava com o GetRight bombando downloads de todo uma plataforma nova: JBoss 4.0.4, JBossIDE 1.5.1, JBossCache e as novas especificações JSR do Java. Acabei perdendo um tempão organizando arquivos localmente e apagando coisas antigas.
Finalmente, olhando o JBoss Seam (veja um tutorial aqui) me levou ao Merlin e ao Apache Beehive. Se eu considerar o Merlin como projeto pioneiro de 2001, eu considero o Seam e o Beehive cópias expúrias do Merlin, uma vez que (podem querer provar o contrário) a idéia de ambos é fazer um model-based development, onde a navegação (controle) do sistema é definida já nas classes POJO (Javabeans) do sistema, via anotações (JSR 175) e arquivos de configuração. Ah, se eu tivesse uns 200 programadores para fazer o Merlin pra mim!
Agora, continuo com o country rolando no last.fm (mas com o VLC cheio de buffer pra dar conta da rede Virtua, que tá uma droga - embora tenha melhorado durante a noite e agora de manhã....mas ainda tá muito longe daqueles 2Mb que eles me prometeram).
So...café, banho e cama.

JavaOne e mais Ajax

Ajax
Ontem o tempo estava bom para pesquisar e resolvi dar uma olhada como andavam as coisas sobre Ajax pelo mundo a fora. Claro, muita coisa existe e, obviamente, não dá pra olhar tudo. Assim, vai abaixo os comentários sobre o que eu andei olhando e minhas percepções.
Vários frameworks e APIs existem para o Ajax, como o Backbase, Dojo, Rico, GWT, DWR e outros. O DWR eu já tinha ouvido falar e consiste em uma API que permite a chamada de métodos remotos assincronamente, usando as funções de callback, as quais eu já comentei no post passado. Basicamente o DWR é composto de um conjunto de scripts que são atachados a página e um componente que roda no servidor, ou um servlet. Ele cuida do marshalling de dados entre as partes e as funções callback são o elo de ligação entre o java e o javascript. Bom, mas isso todo framework Ajax faz! OK, mas o DWR possui soluções boas e exemplos de como integrá-lo a outros componentes mais "pesados", como o JSF e o Struts. Outra API é a Backbase. Ela também oferece os recursos do DWR mas agrega componentes próprios, os quais funcionam como taglibs do JSF. Fora isso ambos são iguais. O Rico é outro framework que objetiva RIA (Rich Internet Applications) com Ajax. Olhando os exemplos do site, mais parece que os caras estão tentando fazer um "Power Point" com as aplicações. Vi muito efeito de drag-and-drop, mas muito pouco sobre coisas úteis para desenvolvedores de sistemas de dados, como integração com frameworks (JSF, Struts, WebWork, ...) ou interação com elementos de back-end (EJBs, Webservices, ...). O Dojo é mais num no cenário. Achei o site bastante "fraco", principalemente para algo "ajaxiano". Finalmente, achei o GWT, ou melhor dizendo o Google Web Toolkit. Mesmo na versão beta, esse vale um post no Coisiboa. Em suma, com ele você pode até esquecer que programa na web - nada mais de HTML se não quiser. Ele possui um framework próprio de componentes UI, tal como o Swing. Também possui um bom suporte a eventos e, pasmem, traduz seu código-fonte em Java para Javascript com muita precisão. O Ajax vem embutido (pra variar) com as funções callback. Também tem uma boa documentação, exemplos e utilitários para criar aplicações de template e projetos no Eclipse (mas não é um plugin, é um utilitário de linha de comando). Obviamente, tem limitações: não suporta sintaxe Java 5, faz restrições em funcionalidades e APIs nativas do Java (como List, Threads...) e tem que cuidar coisas como serialização de objetos. Fiz uma aplicação de teste com ele e gostei do resultado.

JavaOne
O JavaOne rolou esse mês e, claro, o assunto não poderia ser outro: o J2EE 5 e o Mustang. O J2EE saiu e muitas coisas estão para mudar. Dicas sobre como usar corretamente (os famosos) blueprints nos vastos recursos da plataforma (annotações, defaults, injeção de recursos, ...) e como integrar ferramentas foram tópicos discutidos nas sessões do evento. Sobre o Mustang as boas novas foram, claro, para os recursos desktop. O suporte nativo para TrayIcon, o gerenciador de layout GroupLayouyt (que ainda deve ser incluso), e a classe Desktop, para integração nativa de recuros do SO. Outros "improvements" menores como ajustes na API 2D e gerenciamento de threads do Swing. Ben Galbraith ainda deu boas dicas sobre como usar as Actions do Swing (e isso me lembra muito o que estou implementando no Merlin) e como externalizar recursos como layout e aparência no Swing com o uso de CSS. Finalizando, indicou fortemente o uso de gerenciadores de layout como o GroupLayout (do Matisse Netbeans) e o FormLayout (do JGoodies).

Como disse, o Ajax veio pra ficar. Quer saber mais sobre ele é só procurar no Google. Um bom início é o Ajaxian e o Ajax Resource Developer Center. O J2EE 5 pra mim não é novidade, pois já usamos ele a um bom tempo na 3Layer. O que muda é que agora as coisas podem acontecer "sem poréns". O Mustang tá no forno. Não me atrevi a usar ele na íntegra, pois "core" é "core". Assim, somente no ambiente de teste. Sabe como é: é bom, mas temos tempo ainda.

Alguns links relacionados
http://java.sun.com/javaone/sf/sessions/general/javablueprints_thursday.jsp
http://java.sun.com/javaone/sf/sessions/general/mustang_thursday.jsp
http://java.sun.com/javaone/sf/sessions/general/eight_ways_dev_swing.jsp
http://java.sun.com/javaone/sf/sessions/general/intro_ajax.jsp
http://java.sun.com/javaone/sf/sessions/general/sun_friday.jsp
Prototipe JavaScript Framework
Scriptaculous (outro framework Ajax)

Ajax: A revolução nos cadastros?

Esse é meu primeiro post no site. Nem sei porque estou escrevendo agora, porque tenho prova amanhã e não estudei nada - fiquei o dia inteiro fazendo frame na tela (clique com o mouse em um lugar que não tem nada no desktop e arraste para qualquer lugar que não tenha nada: pronto, você fez um frame!).
Bem, o que quero falar é sobre o Ajax e sua relação com Java. Assim, parece que o assunto não tem muito a ver com telas de cadastro, mas é bem ao contrário.
Ajax nada mais é que um nome bonito para uma tecnologia velha (HTML dinâmico + Java Script). Na prática o Ajax padroniza (?) tipos de controles de tela (em frameworks, como o Backbase) e operações (eventos, como clicar, arrastar, passar o mouse, etc.). Essa padronização á baseada em conjuntos (enormes) de arquivos de JavaScript que fazem operações diretamente no modelo DOM (Document Object Model) da página. O DOM é uma árvore em memória que é a representação de todos os elementos que aparecem na tela do usuário (botões, imagens, tabelas, texto, etc.).
O legal nessa tecnologia é que as chamadas dos métodos javaScript ocorrem em segundo plano. Assim, enquanto o usuário está digitando algo em uma caixa de texto, um código JavaScrips (ops, Ajax) pode estar enviando um arquivo para o servidor ou adicionando itens em uma caixa de seleção.
Devido a proliferação do Ajax, estamos entrando na chamada Internet 2, ou Web dinâmica. (Sobre isso tenho um comentário. Internet 2 e Web Dinâmica é uma coisa de se pensar. Anos atrás quando se falava em Internet 2 esperava-se que ela fosse conhecida como Web Semântica, ou seja, um lugar onde houvesse menos redundância de informações e os resultados dos buscadores - como o Google - tivesem menos resultados e mais confiabilidade. Porém, vejam como realmente as coisas mudam...).
Continuando. O Ajax é bom, embora ainda seja complicado e não seja um padrão (pois não existe uma especificação - qualquer empresa cria um framework com suas regras).
E o Java? A relação do Ajax com o Java é muito estreita. Geralmente os desenvolvedores utilizam o Ajax para tornar os sistemas mais rápidos, pois o usuário não precisa esperar para ver o resultado de uma ação (por exemplo, ele não precisa clicar no botão "Salvar" para que os dados que ele digitou sejam validados, tudo ocorre em segundo plano com o suporte do Ajax).
O problema é que os dados que o usuário digitou precisam ir para algum lugar, provavelmente serem salvos em um banco de dados. E aí as coisas complicam, pois o Ajax não faz esse trabalho. Para esse trabalho é usado o Java. Assim, é necessário um mapeamento de dados que estão no domínio do Ajax para o domínio do Java, o qual vai efetivamente salvá-los no banco de dados.
E é esse o ponto que considero o Ajax ainda incipiente. Para resolver esse problema ele implementa o conceito de funções de callback. Trocando em miúdos, o Ajax funções são passadas como parâmetros de um lado para outro e é nesse ponto que as conversões de dados ocorrem.
As funções callback sempre foram um problema para mim. Lembro delas quando trabalhava com Delphi e precisava usá-las para enumerar os handles (janelas) do sistema. Isso era preciso porque a API do Windows não disponibiliza um método que retorna uma lista dos handles abertos, mas sim uma função chamada GetHandle que espera como parâmetro a função callback. Assim, uma interação entre a API do Windows e a função callback que eu programei acontece. É nessa função callback que os handles do sistema são computados. O processo é complicado, eu sei. E é o mesmo princípio com o Ajax e o Java...
Funções callback ao meu ver são uma solução ruim para um problema que na verdade não foi bem explorado. E não foi explorado porque não existe um trabalho unificado, que culminaria com uma especificação.
Bom, e o que as telas de cadastro tem a ver com tudo isso? Tudo.
O princípio básico de preenchimento de telas de cadadastro vai mudar radicalmente na web. Em suma, os usuários não vão mais submeter dados errados para os servidores. Tudo que for enviado já terá sido validado no próprio cliente. Além disso, questões de usabilidade serão afetadas. Por exemplo, o número de cliques necessários para enviar os dados de uma tela de cadastro vai reduzir, bem como n tempo necessário para preenchê-las. Outro aspecto é que muito código que antes estava no servidor será migrado para o lado cliente. É uma nova fase da luta thin clients x fat clients (clientes magros x clientes gordos). O que pode ocorrer é, novamente, duplicação de regras de negócio (sistemas de legado ainda precisam manter as regras de negócio - diga-se principalmente validação - no lado servidor, porém novas interfaces de cliente já saem com essas regras duplicadas am código Ajax. Isso acontece porque regras simples como tamanhos mínimos, máximos, obrigatoriedade e testes com expressões regulares não envolvem o servidor remoto e são integralemnte processadas pelo Ajax. Mas elas também devem estar presentes no servidor remoto, uma vez que acessos por sistemas de legado ainda podem ocorrer.).
Com o tempo, o Ajax vai melhorar e as coisas devem convergir (eu espero). Se eu pudesse pedir algo, seria uma especificação e uma implementação de referência, tal como existe para o JSF. Como isso não pode ser pedido pra ninguém, o jeito é testar vários frameworks e esperar que algo melhor que as funções callback apareca no mercado.