And JavaScript wrath strikes again

Bom, eis que tentei começar as coisas pelo jeito 'sofisticado e elegante', ao invés de ir pelo simples. Explico-vos.

Hoje foi dia de implementar o envio de informações do cliente ao servidor. Primeiramente preparei um mecanismo rudimentar, por enquanto, para enviar para o browser um top Widget (AppFace) como apresentação. OK. Então, ali teria um botão para enviar um evento para testar a sincronização. Aí começa o suplício.
Inventei de usar um objeto XMLHttpRequest para fazer a requisição sem precisar de outro frame, e aí estava o problema: como eu escuto por eventos em outra porta, por precisar de um fluxo constante de dados vindo pelo stream original; o Mozilla não me permite conectar em outro 'servidor' (outra porta também) sem ter UniversalBrowserRead, o qual eu não tinha como obter. Tenta alteração aqui, tenta alteração ali, e nada. Realmente eu não tinha como usar o XMLHttpRequest. Porcaria. Desfaz alteração aqui, desfaz alteraçao ali. Volta pro começo.

No fim, tudo que precisei fazer foi, por javascript (function sendEvent()), dar um submit() num form escondido no controlFrame, e, ao tratá-lo, enviar um HTTP 204 (no content). Tão mais simples... e funcionou tão bem...

Ao fim, já temos um mecanismo que recebe direito eventos da apresentação e pode tratar eles, apesar de ainda não o fazer. Muito bom.

Uma revisão das coisas a serem feitas nos indica:

• precisamos ainda poder delegar a um componente um evento recebido; isto será fácil;
  
• precisamos definir direito e dar um lock temporário na API dos componentes gráficos. Se não a coisa pode ficar caótica, apesar de ainda estar bem no começo;
• dar jeito de fazer embedded browser funcionar para carregar a aplicação ele próprio;
  

Das coisas que estavam por fazer, já está definido:

• o nome do framwork é o criativíssimo PyWAF: Python Web-like Application Framework. Pelo menos é um nome que dá um acrônimo sonoro. PyWAF.
• a sincronização de eventos está ok;

Creio que o próximo passo é melhorar o set de componentes para eles conseguirem fazer algo prestável.

Python é legal.

News from the front

E mais um dia de desenvolvimento:

• Já há um PyMozEmbedd funcionando, mas ele, por alguma razão que eu ainda não entendi, não completa uma conexão sequer quando chamado de dentro do mesmo processo que o resto da aplicação; entretanto, abre outras páginas e, rodando stand alone contra o servidor, funciona perfeitamente. Tenho que dar jeito nisto.
• Já envio um esqueleto HTML pro browser e já tem lugar pra encaixar algum comportamento.

• Dei uma limpada na estrutura do código, separando ele em arquivos diferentes, conforme for pertinente. Nisto, também, todos os widgets foram para o seu módulo.

Partes importantes que eu preciso fazer agora são implementar um controle da aplicação em Javascript e fazer os Widgets fazerem algo de verdade. Vamos ver no que dá... eu estava me enrolando um pouco pra fazer uma função javascript submeter um form de outro frame: o Mozilla me informava que eu não tinha permissão para acessar o objeto. Provavelmente isto tem a ver com o fato que eu estava buscando cada frame por uma porta diferente e ele restringe o acesso às informações entre frames que vêm de servidores diferentes. Coisa bastante inteligente, na verdade.

Notas aleatórias

Definitivamente não gostei do fato de BaseHTTPServer.py logar cada conexão por default. Vou ter que alterar algumas coisas no módulo. Inclusive a DEFAULT_ERROR_MESSAGE.

Mais coisas a fazer

A sincronização de eventos está ok.
Algumas coisas novas que ainda têm de ser feitas:

• Encontrar um nome para o framework
• Definir uma api para implementação dos componentes de tela (Widgets)
• Definir uma api para composição de interface
  

Initial Report

Então há um blog novamente.

Mas não nos prendamos a detalhes e vamos ao que interessa.

Há este projeto de um framework para desenvolvimento de aplicações executando localmente, mas com uma interface web. Interessante pra desenvolver alguma coisa usando web (browser) como meio, mas não tem em vista uma aplicação web propriamente dita. O que estou desenvolvendo cuida da comunicação entre o browser (cliente) e a aplicação (servidor) fazendo todo o trabalho de comunicação entre os dois pela rede. Para guiar o desenvolvimento e para criar situações de problemas reais, assim que possível começará a ser desenvolvida uma aplicação exemplo; a saber, um RSS aggregator.

Comecei o desenvolvimento disso segunda feira, fazendo um esboço bem geral do que eu queria, do que eu precisaria fazer e de como eu poderia. Nisto decidi as linhas gerais da arquitetura e que seria útil ter um componente servidor http pronto, para que eu não precisasse escrever um eu mesmo. Comecei a tentar fazer em python, mas a linguagem é nova e só peguei o jeito com ela hoje, o que mostra que ela é bem fácil (mas isto também foge ao ponto, apesar de que vai ser de algum entrave pro desenvolvimento). Provavelmente isto vai ser só um protótipo e, após ter resolvido grande parte dos problemas de design do framework, vou reimplementar em Java.

Até o momento já tem o servidor que vai mandar os dados pro browser e um servidor que escuta por eventos. Já dá pra ouvir de um lado e falar de outro. Estão em thread separadas. Há também um mecanismo rudimentar, não testado, de componentes.

Os pontos importantes de se preparar logo é:

• Conseguir sincronizar o envio de algum dado com a ocorrência de algum evento
• Delegar a um componente registrado a função recebida pelo tratador de eventos