Prometi para mim mesma que hoje antes de dormir iria dar uma boa olhada no JQuery e cá estou. Fiz todo o tutorial do Caio sobre a biblioteca e depois ainda brinquei mais um pouco (só html e js mesmo). Foram fortes emoções. A biblioteca é muito legal! 
Agora passei para ler um pouco de teoria. Estou com estes tutoriais:
Depois disso vou pegar outro um pouco mais aprofundado. 
Bom, fica a dica, pessoal. Depois dessa acho que não volto pro prototype tão cedo. Valeu, Caio!
Não, nem eu e nem ninguém sabemos muito a respeito dessa nova linguagem anunciada há poucos dias pela Microsoft. Segundo o que dizem, será uma linguagem de descrição de dados com suporte a OO, parecida com XAML. Terá integração com o Visual Studio (afinal é da M$), mas poderá ser compilada no Linux e Mac também (quero só ver!).
Bom, agora é aguardar pra ver se pega…
Mais informações em:
http://thecoffeedesk.com/news/index.php/archives/74
Bom, se você, assim como eu, está dando manutenção em alguns sistemas legados da sua empresa que infelizmente não utilizam frameworks que já oferecem suporte à internacionalização, chegou a hora de parar de ficar olhando de cara feia para as mensagens escritas diretamente nos JSPs e colocar I18N utilizando JSTL!!
Ainda estou pesquisando a fim de descobrir se a forma que irei apresentar é a ideal e a de melhor desempenho, mas.. é aquela velha história: funcionar, funciona! 
Passo 1: Crie um arquivo de propriedades
Crie um arquivo de extensão properties (ou mais de um, dependendo de quantas línguas você irá internacionalizar seu projeto) e coloque ali o conjunto de chaves necessárias para a I18N. Um arquivo de propriedades é composto por chaves e valores separador por igual (”=”).
Um exemplo de conteúdo deste tipo de arquivo seria:
# ---------------------------------
# Propriedades do SISTEMA X
# ---------------------------------
# --~--~---------~--~
# ARQUIVO: login.jsp
# --~--~---------~--~
login.label.login=Login:
login.label.senha=Senha:
login.botao.cadastro=Cadastro de Usuário
login.botao.login=Login
# --~--~---------~--~
# ARQUIVO: relatorios.jsp
# --~--~---------~--~
relatorios.title=Relatórios
Passo 2: Crie uma classe Java para pegar o valor das propriedades
Um exemplo de implementação:
import java.util.MissingResourceException;
import java.util.ResourceBundle;
/**
* MyProperties class.
*
* This class was created in order to get strings of the properties file.
*
* @author thania
*/
public class MyProperties {
/**
* A ResourceBundle instance to refer the MyProperties file.
*/
private static ResourceBundle resourceBundle = ResourceBundle.
getBundle("pacote.MyProperties");
/**
* Gets the string of the ResourceBundle instance.
*
* @param key The key for searching the string.
* @return The value that was searched in the properties file.
*
*/
public static String getString(String key)
{
String value = null;
try
{
value = resourceBundle.getString(key);
}
catch(MissingResourceException e)
{
e.printStackTrace();
System.err.println(new StringBuilder("ERROR: Properties :: getString -> ").
append(key).append("\n").append(e));
}
if (value == null)
{
System.err.println(new StringBuilder("ERROR: Properties :: getString -> ").
append(key));
}
return value;
}
}
Passo 3: Configure o web.xml
É preciso informar no web.xml qual será o arquivo que contém as mensagens do seu sistema. Para isto, basta adicionar a seguinte configuração no arquivo:
<context-param>
<description>Arquivo de propriedades do Sistema X</description>
<param-name>javax.servlet.jsp.jstl.fmt.localizationContext</param-name>
<param-value>pacote.MyProperties</param-value>
</context-param>
Passo 4: Use I18N no seu JSP!
Para utilizar as mensagens nas suas páginas JSP, importe a taglib fmt do JSTL:
<%@ taglib uri="http://java.sun.com/jsp/jstl/fmt" prefix="fmt" %>
Setar a classe que cria uma instância de ResourceBundle para buscar a valor no arquivo de propriedades:
<fmt:setBundle var="messages" basename="pacote.MyProperties"/>
E, finalmente, use no texto do formulário:
<fmt:message key="login.label.senha" bundle="${messages}"/>
Isso retornará: “Senha:”
Enjoy! 
ps.: Se alguém tiver uma maneira melhor de fazer isso, por favor, mande-me um comentário. Nesse caso, não vale usar framework. Estou com um sistema legado aqui sem direito a refactoring e replanejamento da arquitetura, por enquanto. :~(
Tá. Eu sei que incompatibilidades entre navegadores existem desde antes de eu nascer mas, cá entre nós, pimenta nos olhos dos outros é refresco…
Bom, as minhas atuais tarefas do meu trabalho estão envolvendo bastante Javascript. Como se trata de um sistema web, fico volta e meia testando no IE6, IE7 e Firefox. Resultado: cada dia fico mais indignada com a falta de padronização e compatibilidade destes browsers. Dá muita raiva. Inocentemente, no início fiquei testando mais no Firefox, afinal pra mim é mais conveniente, já que é meu browser padrão. Acabei me empolgando pra fechar um requisito e assim que deu tudo certo no Firefox, fui testar no IE e bumMmMmMm… Quanta coisa bugada! E pra descobrir qual o problema é um outro dilema, afinal no IE não tem o Firebug para me ajudar a debugar e, contraditoriamente, tudo costuma funcionar na mais perfeita ordem no Firefox (ele sempre é mais espertinho :). Tenho que ficar disparando vários alerts no meio do código pra ver em que função deu problema - aquele information de bug que fica no lado esquerdo da barra de status do IE não ajuda muito quem usa Linux. Tá louco, programação do tempo das cavernas… Snif snif.. :/
Ok, eu confesso, algumas funções que eu estava usando eram das versões mais atuais do Javascript e não ía pegar mesmo no IE. Troquei o que pude para as funções do prototype e a maior parte do requisito passou a funcionar no IE. Ufa! Mas mesmo assim né, dá um tempo, não precisava ser assim…
Antes disso, o problema foi com o CSS - pois é, de vez em quando eu dou uma de designer. Sinceramente, não arrisco dizer o que é mais incompatível entre browsers, se é o Javascript ou CSS. E pra CSS, você ainda tem que testar tanto no Firefox do Windows quanto do Linux, pois acontece de a tela ficar diferente dependendo do sistema operacional, acreditem se quiser. Também faço dar suporte pra IE6 e IE7 e, sinceramente, preciso dizer, no IE6 a coisa é na raça! É incrível como muita propriedade legal que funciona no Firefox, simplesmente só faz cócegas no IE6. Sorte que são poucos os que usam IE6, atualmente. Ainda bem que o IE7 já melhorou muito em relação a CSS. Temos max/min width/height, background transparente.. que blz.
Eu ficaria muito feliz se todos utilizassem apenas o Firefox, mas isso dificilmente aconteceria muito em breve. E mesmo se aumentasse o número de usuários Firefox, mesmo que fosse uns 40% a mais que o total de usuários atual, ainda assim teríamos usuários IE e precisaríamos dar suporte a eles. Eu, ao menos, não acho nada legal forçar o usuário a utilizar um browser X. Quem não fica indignado quando vai acessar um site e ele diz algo como “esse site não dá suporte ao browser que você está usando, use o browser X”. Poxa, eu fico chateada… Estou careca de saber que é complicado implementar de maneira que fique igual (ou ao menos parecido) em todos os browsers, mas não é impossível, é só ser um pouco mais.. errr, hmmm, digamos… paciente e persistente. Cá estou eu aqui reclamando deste problema, mas jamais tomei uma decisão drástica dessa em sistema web e espero não precisa tomar.
O jeito é torcer para o IE8 dar um pouco mais de bola pro Javascript dessa vez, invés de só para o CSS…
Bom, pessoal, desculpa o desabafo. Me sinto bem melhor agora.
Boa dia a todos!
Oi!!
Saiu na revista Java Magazine desde mês uma edição sobre o Apache Wicket, um framework baseado em componentes para o desenvolvimento de aplicações web em Java. 
Sinceramente, não me lembro de ter ouvido falar dele.
No artigo da revista, mencionam que o Wicket já é comparável com JSF e Tapestry. Além disso, segundo ao Wiki, ele se tornou um projeto de “nível alto” da Apache em junho de 2007. HmmMmM.. Será que já não é uma boa hora de dar uma olhada nesse cara?
Bom, fiquei curiosa. No site oficial do projeto, tem um exemplo de “Hello World” utilizando o framework. Parece bacana. Vou tentar dar uma testada em casa e descobrir se pessoas que já o utilizam em projetos, recomendam. Se for um EJB 2.x da vida não dá pra investir… 
O Wicket já está na versão 1.4 e o artigo da revista Java Magazine falou muito bem dele. Acredita-se estar bem estável.
Aguardem posts a respeito!
“Girls are made of sugar and spice, and everything nice…”
