quarta-feira, 13 de maio de 2015

SMOOTH o sonho das consumidoras e consumidores...

Estava procurando na web e encontrei a solução que faltava para tornar a pele mais macia, lisa, bonita, leve,...., chama-se SMOOTH DREAM... Ta no post errado? acho que não, pois todo desenvolvedor Genexus Web hoje esta 'sonhando' com o produto: SMOOTH, aquele que deixa sua interface web exatamente com essas características: macia, lisa, leve, bonita,... A questão é que não se trata de uma pastinha, um pozinho, e sim do mais novo recurso da EV3. Aqui exploraremos um pouco da capacidade do Web User Experience = SMOOTH do Genexus Evolution 3 e seu impacto nas nossas telas.

Smooth revoluciona a maneira com que a pagina Web é carregada, e o seu objetivo principal é reduzir ao máximo a quantidade de bytes trocados entre o servidor e o browser, e como consequência sua aplicação gera interface com maior desempenho.

Modo Compatível

Nas versões anteriores do Genexus, Web User Experience = Previous Version Compatible, ao se clicar em um evento de servidor, um botão Confirmar, por exemplo, toda página era reconstruida, fazendo com que qualquer ação que o usuário gerasse, causasse lentidão, por conta do processamento no servidor, transmissão de dados pela internet e a recarga no browser.

Vamos a um exemplo, imagine a interface abaixo, com três controles grids. Ao se gerar um evento no Grid1 (cidade), clicando no nome da cidade por exemplo, isso faz com que o Grid2 (clientes) seja recarregado. No modo tradicional, leia-se Ev1, Ev2, e anteriores, o resultado seria carregar: A Master Page, a pagina web toda com o Grid1, Grid2 e Grid3, incluindo ainda nesta conta, tudo que tem na Master Page como a construção do menu de opções, os controles de segurança, ou seja, um simples clique no Grid1 gerava um custo altissimo.


Neste mesmo exemplo, somente para termos uma noção dos valores, abrindo o Fiddler para recuperar a comunicação entre o browser e o servidor teríamos uma visualização de tudo que foi transmitido, ou seja todos os elementos necessários na interface, incluindo HTML, CSS, IMAGENS, JS, ou seja, tudo. E claro o browser deveria receber e recalcular tudo para colocar no devido lugar.

Em dimensões numéricas seria algo em torno de: 47.064 Bytes, num tempo estimado de 525 microsegundos (para localhost).

Neste modelo todos os eventos são executados na sequencia:
START-
-EVENTO USUARIO-REFRESH-LOAD


Smooth

Passando um pouco do produto de beleza, ou seja, selecionando a opção: Web User Experience = Smooth, esta mesma interface geraria um modo de navegação totalmente diferente, nada seria recarregado na interface a menos que o próprio desenvolvedor programe comandos REFRESH nos componentes. Desta forma seria necessário que ao interceptar um clique no Grid1, que o Grid2 seja atualizado por meio de um comando Grid2.Refresh(), tal qual apresentado a seguir.

Event Grid1.OnLineActivate
    &CidadeId =CidadeId
    Grid2.Refresh()
endevent


Os eventos neste modelo ficam limitados a
- EVENTO USUARIO


Sabe o resultado disso? somente o Grid2 será atualizado, todo resto da interface permanecerá do mesmo jeito.  A comunicação será limitada a uma chamada AJAX ao servidor para obter a carga do grid2. No nosso caso reduzindo a para apenas 1.452 bytes. O Fiddler devolveu míseros 31 milissegundos neste exemplo.

Mas já da para tirar uma conclusão, você prefere  uma comunicação que transmita 47.064 Bytes a cada retorno ao servidor, ou a carga inicial completa e em seguida chamadas menores com aproximadamente com 3% desse total. E melhor, sem reconstruir master page, recarregar menus e outros penduricalhos da interface?  Não precisa nem me responder, já sei a resposta.

Bom, precisamos terminar a 'venda' do produto, que você pode obter por meio das nossas consultoras de plantão.