MouseOver Studio

Nessa semana saiu o primeiro servidor de Ajax. Ele foi chamado de Jaxer e foi desenvolvido pelos caras de Aptana. Cid Andrade fez um review dele e também falou um pouco sobre o relacionado com seguridade.

Fiquei muito interessado e surpreso com o servidor e como não achei nenhuma aplicação de teste decidi baixar o servidor e experimentar um pouco, ver como eram renderizadas as paginas e se o processo era rápido ou não.

O primeiro passo foi descarregar o servidor desse link. Gostaria de poder ter testado ele em Linux mas ainda não esta disponível. O servidor ja vem com o servidor de Apache embutido e pesa 14 Mb.

A instalação e muito simples, basta com descomprimir o arquivo zip e para iniciar o servidor somente teve que executar o arquivo
StartServers.bat . Nesse momento é aberta uma janela de console e são criados 5 processos: dois httpd.exe, três Jaxer.exe e um JaxerManager.exe . Não sei por que existem dos processos httpd.exe e três Jaxer.exe, é algo que terei que pesquisar.

Ao entrar no endereço http://localhost:8081/aptana/ é apresentada uma página com informação sobre o servidor e alguns links. Um dos links era chamado Samples and Tools e como eu queria fazer uns testes, nada melhor que seguir ele. O link abriu umas paginas com as mesmas aplicações de demonstração que se encontram aqui.

Habilitei o FireBug e comecei a navegar pelas aplicações, analisando algumas coisas. Uma coisa que percebi era que em toda pagina eram inseridos dois trechos de código em JavaScript que não estavam na fonte original. Procurei e consegui achar um deles, o qual vem de um arquivo chamado clientFramework_compressed.js . Como o nome diz, o codigo esta compactado e não da para entender muita coisa, mas felizmente a fonte limpa se encontra na mesma pasta chamada framework.

Continuei comparando os códigos originais das aplicações com os resultantes e pode apreciar que efetivamente os scripts que rodam no servidor não são mandados pro cliente. Mas que acontece no caso em que uma função local precise chamar uma função a ser executada no servidor? Nesse caso temos que assinar o valor true ao atributo proxy da nossa função a ser executada remotamente. Parece que quando o Jaxer percebe que existe uma função no cliente que tem que se comunicar com uma no servidor ele envia duas funções pro cliente chamadas xpto() e xptoAsync(), supondo que nossa função original se chame xpto. Desse modo, se temos uma seguinte script a ser rodado no servidor:

function save(contents)
{
	contents = contents.replace(/\r\n/g, "\n");
	contents = contents.replace(/\r/g, "\n");
	checkValid(contents);
	Jaxer.File.write(getFilePath(), contents);
}
save.proxy = true;

no cliente ira chegar o seguinte:

function save() {return Jaxer.remote("save", arguments);}
function saveAsync(callback) {return Jaxer.remote("save", arguments, callback);}

Os scripts a serem executados em ambas camadas (runat=”both”) são enviados intactos para o cliente. E importante mencionar que em todos os casos o atributo runat e retirado da tag script, assim que parece que não tem jeito de saber se o script pode ser executado também no servidor ou não.

Antes que esqueça, quando analisei os arquivos fontes abri eles no Aptana Studio e algo que achei legal foi que ele pinta o fundo do script dependendo do atributo runat. Se o valor do atributo runat for server então o Aptana pinta o fundo de uma cor azul, caso for both ele pinta o fundo de uma cor meia laranja.

Realizei uns quantos eventos que precisavam fazer chamadas ao servidor e analise no console do FireBug as petições. Em todas elas era enviada ao servidor informação do seguinte tipo pelo método post:

id	               -1705679199
methodName	proxyLog
params	           ["warn","a proxied 'warn' log statement"]
uid	             1201567523859_501925

O id nunca mudava numa mesma aplicação. Pode ser o id do cliente, da aplicação ou da função, é algo que ainda tenho que descobrir. O methodName é o nome da função a ser executada no servidor, params contém os parâmetros exigidos pela função e uid é um valor que também não sei o que representa mas sempre foi mudando em cada solicitação.

Uma outra coisa interessante do Jaxer é que ele pode ser integrado facilmente com MySQL. Dentro da pasta raiz do Jaxer temos uma pasta chamada local_jaxer e dentro dela outra chamada conf, onde existem três arquivos: config.js, configLog.js e configRoutes.js . No primeiro arquivo podemos configurar a integração com o MySQL especificando usuario, host, porta, senha e base a ser utilizada, assim como outras opções do servidor. No segundo arquivo podemos configurar como queremos que o log trabalhe e no ultimo as regras para redirecionamento das paginas. Podemos por exemplo configurar para que ao cliente se dirigir no link xxx.host/yyy ele seja redirecionado para a aplicação yyy dentro da pasta xxx.

Por aqui termina meu primeiro contato com o Jaxer, espero que no futuro possa ter experiências e analises mais profundos desta ferramenta que como mencionei anteriormente, chama muito minha atenção.