Falaê pessoal 
Estava passeando na net hoje de manhã como de costume, e me deparei com um brinquedinho muito interessante: Thinlets.
Alguem ja usou ou testou esse cara? O que achou?
Parece ser muito legal.
Oque eu ja tinha visto e testado era um programa que convertia arquivos .ui do QtDesigner para uma aplicação swing, idéia legal, mas tinha seus probleminhas.
Curioso é que esse conceito já existe entre aplicações GUI usando toolkits como QT e GTK a tempos.
Pois eh, o Mozilla tambem é baseado em XUL. Usar uma definicao pra montar a UI realmente nao eh nenhuma ideia nova…
Mas, PUTA MERDA, 50KB UM APPLET QUE FALA WEBSERVICES COM A AMAZON!? Meu, esse codigo eh muito bem-feito. Muito pequeno. Roda em iPaqs, Zauruses, e outros dispositivos que mal aguentam uma VM decente… 
Tambem fiquei coloco quando rodei o exemplo da Amazon! Show de bola.
Ai fui tentar rodar o exemplo pra midp e o negocio simplesmente foi pro vinagre, pela classe ser um JUMBO de 124k, o palm que usamos se recusou a instalar o midlet…
Isso é outra coisa meio ruim, pq tudo tem que ser 1 classe só? O fonte é 1 bomba só de 210k. Vejo spaghettis maiores que esse em programas em C, mas mesmo assim fazer isso só pra ganhar alguns bytes no tamanho total da aplicação?
Pois é, coisa feia 
Achei o treco muito massa. Achei excelente para fazer um appletzinho com recursos visuais mais elaborados. Muito bom mesmo.
O unico problema eh que ele tem uma fome por recurso do caralho. Nao tem como colocar mais que 2000 registros nas listas ou nas tables que o componente nao aguenta.
Quanto a organizacao do codigo, achei a maneira nao muito usual, mas pratica. Na verdade ele trocou a ideia de orientacao a objeto por estruturacao em XML. Os objetos todos sao agragados uns aos outros numa arvore xml, logo nao fazia mais sentido organizar as funcoes para tratar desses objetos em classes separadas.
Soh acho que o autor poderia realmente separar um pouco mais as funcoes, e fazer os metodos serem ao menos protected, a fim de poder reescrever funcionalidades por heranca.
heranca sux
ei
deem uma olhada no codigo fonte do cara
tem TUDO la num soh arquivo: desde o parseador de XML ateh o gerenciador de layout. BIZARRO.
Eu tb achei muito legal até ver o tamanho da classe.
Economizar número de classes é o cúmulo. Até parece que os metadados de uma classe ocupam tanta memória assim. Já vi gente reduzir a quantidade de interfaces, acho que se vc tá num ambiente como um palm, não é mesmo pra esbanjar.
Mas já vi coisas mais bonitas feitas com reflexão. Nada tão genérico como o Thinlet, mas tem.
Conceitualmente, daria pra fazer um único EventListener usando a técnica de event listeners genéricos do site da sun e um Invoker configurável em XML baseado no Easy Actions Framework (se é que é esse o nome).
Não adianta vc ter uma classe só se vc tem milhares de instâncias dos objetos, ou se vc gasta sua RAM inteira com XMLs. o legal é parsear uma vez e só. Por isso, um thinlet animal ia ter uns poucos renderers, uns poucos editors, uma imagem cacheada representando a Content Layer e uma matriz (sei lá como seria implementada) de regiões para catar cliques do mouse. Se você não deixa o cara fazer resize (por exemplo, um applet, ou uma app num palm), vc não tem que ficar brincando com LayoutManagers.
Quando vc tivesse um evento, iria processar o evento, e qualquer coisa alteração “gráfica” iria ser feita no renderer, incorporada à imagem original e pronto.
O ruim seria acabar tendo restrições do tipo: “todos os JLabels têm o mesmo tamanho”, “todos os JTextField têm a mesma fonte”. Mas em muitos casos dá pra viver com isso.
Claro que assim, vc quebraria o desenho “Beans” do Swing. Mas a idéia é exatamente essa, vc não quer delegar tudo e ter cada um tomando conta só de si. Vc quer um cara só pra fazer tudo.
[]s!!!