Neo Framework Forum

http://neoframework.svn.sourceforge.net/viewvc/neoframework/trunk/Neo/src/br/com/linkcom/neo/persistence/GenericDAO.java?revision=2&view=markup

ver Linha 213

Coloque essas configurações em um arquivo de properties e deixe ele na raiz do jar.
Depois defina uma tag no web.xml que a pessoa possa carregar esse arquivo de um diretorio da aplicação dela (classpath).
Assim ela pode copiar o properties com todas as configurações avançadas do neo (se quiser), colocar no classpath da app dela e trocar o comportamento do framework em casos especificos.

Esse esquema de cache do combo também é perigoso. Eu posso querer eliminar de uma consulta especifica. Tem jeito?

Bacana

Seleção é automatica com base no computador do usuário (linguagem do usuário). Mas claro tem que ter uma forma de mudar de idioma.

Tenho link não.

Não precisa alterar nada na forma de usar os componentes.

<menu title="menu.cadastro">
<menu title="menu.aluno" url="/login/crud/Aluno" />
<menu title="menu.bolsista" url="/login/crud/Bolsista" />
<menu title="Cliente" url="/login/crud/Cliente" />
</menu>

Pode ficar assim mesmo para manter a compatibilidade das tags.
Ai o componente procura menu.aluno no arquivo de resources e mostra a mensagem do arquivo.
Se não encontrar (caso do 3 item do menu), o componente pode exibir o texto que está em title mesmo.

Então o mesmo menu sem atributos adicionais funciona com internacionalização e sem.

-------------

Agora quanto ao arquivo de resources tem 2 paradigmas:
- Usar padrão Java, onde o arquivo de resources fica no Source, e a cada alteração tem reload da aplicação.
- Usar no estilo Mentawai, onde o arquivo fica em uma pasta dentro do WEB-INF. Então é possível alterar o arquivo a vontade sem reload. Nesse caso existe uma classe que fica analisando se esse arquivo foi alterado, e caso tenha sido o arquivo é aberto e lido - então as alterações refletem na hora.

As duas formas tem pontos negativos.
A primeira tem reload. Mas com a segunda você não pode usar jstl, nem usar código em Java (nativo) que le do arquivo de resource porque ele não existe. Então se fosse usar o segundo caso teria que implementar as suas tags de i18n e faz classes utilitarias para ler esse arquivo em vez de usar o Bundle padrão.

Sei lá, nessa parte eu não tenho opinião de qual é melhor não, pra mim as duas são ruins. Uma quebra compatibilidade, a outra é tosca - faz reload pq vc mudou um arquivo texto... hehe ^^

pedro, vcs n vao colocar no sourceforge?

lá já tem o SVN. Usa o SVN de lá...

o Spider era CVS e tiver que migrar para o SVN que é bem melhor

Fala povo...

Na documentação de componentes senti falta de algo que falasse sobre internacionalização (i18N).
Tanto uma tag de i18n, quanto o uso de i18n em outros componentes como Menu.

Tem isso?