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.
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.
0 comentários:
Postar um comentário