[quote=Monteiro]Utilizamos o VRaptor num projeto para atender uma norma da ANS, chamado TISS. Usamos ele pra fazer toda a parte de controle de interface, jstl pra montar as telas, Hibernate pra persistência e XStream pra parte que tratava de XML.
O sistema ainda não foi pra produção, mas digo que a integração entre o VRaptor e resto foi muito tranquila. Nada como usar anotações em lugar de arquivos de configuração pra botar tudo funcionando, isso pra falar pouco. Há também suporte nativo pra Ajax e mais um monte de coisas que facilitam muito a vida.
Ah sim, vale a pena lembrar também que a integração entre a view e a model é transparente com o uso de EL, nada de usar form beans com métodos get bizarros.
Definitivamente uma ótima opção pra quem quer sair com classe (perdoem-me o trocadilho) do bom e velho Struts :)[/quote]
Hehehehe… coincidência, terei que fazer esse mesmo projeto agora em março.
Bom, apenas para agregar. Comecei a desenvolver web com Java utilizando Struts. No início beleza, não me importava com todas aquelas configurações que tinham que ser feitas, aí me apresentaram o Webwork, (bah) na hora troquei… dali um tempo começaram a vir o JSF, Spring e cia…
Começar a olhar um e outro e ficava louco, mil e uma configuração, precisava de semanas para enteder só o framework, isso me deixava indignado, quase decidi voltar a usar o velho servlet com a JSP.
Até que resolvi ir a fundo no Vraptor, mas pq ele?
1 - Por ser um framework brazuca;
2 - Ter acesso a uma documentação simples e com bastante exemplo;
3 - Por ser simples e requerer o mínimo de configuração possível;
4 - Curva de aprendizado extremamente baixa, isso possibilita treinar uma equipe de desenvolvedores (leigos no assunto) rapidamente.
5 - Suporte e acesso ao desenvolvedores do framework, obtendo respostas rapidamente e também podendo trocar idéia com os mesmos. (Não que isso não possa ocorrer com outros frameworks).
6 - Atende a todos os requisitos que preciso para o desenvolvimento dos projetos que temos na empresa.
7 - To de saco cheio de ficar correndo atrás de frameworks.
Para o desenvolvimento dentro de uma empresa, eu tenho por mim que é necessário se ter um framework em que tu possa focar o desenvolvimento, apostando e tentando contribuir cada vez mais para o aprimoramento do mesmo.
Ou seja, respeito todos os outros, acho que cada um tem sua peculiaridade, mas apostei no VRaptor e é nele que vamos continuar investindo.
Eu também evito usar taglibs dos frameworks mvc. Já que é possível, não vejo porque não desacoplar.
Mas gosto é gosto… não acho que seja um grande problema, apenas evito.
Mudando um pouco de assunto. Fiquei sabendo que o vraptor estaria usando a api paranamer para “descobrir” o nome dos parâmetros dos métodos, e assim melhorar a injeção dos atributos da requisição nas ações. Por exemplo:
versão atual:
public void salvar(Cliente novoCliente){
xxxxx
}
na jsp:
<input type="text" name="cliente.nome"/>
versão usando paranamer:
public void salvar(Cliente novoCliente){
xxxxx
}
na jsp:
<input type="text" name="novoCliente.nome"/>
Lendo esse tópico tão cheio de elogios decidi estudar o framework…espero não me arrepender como ontem numa palestra de Rails (que não vi vantagem alguma)… :twisted:
Eu já havia ouvido algumas recomendações do Fabio Kung…mas não tinha despertado interesse…
Lendo este tópico sobre o VRaptor, dei uma verificada na documentação e percebi que existem algumas semelhanças com o Seam (somente algumas semelhanças!). A questão é. Quem veio primeiro Seam ou VRaptor? E a questão da injeção de dependencias já existia no primeiro release desse framework?
o vraptor veio antes mas as similaridades acabam na injecao de dependencia, que ja existia muito antes do vraptor. e o seam é focado em componentes visuais em vez de “actions”.
Pois é… o VRaptor 1 veio antes do Seam… o VRaptor 2 veio logo depois das versoes beta do Seam, e as primeiras anotacoes do vraptor 1 e 2 foram fortemente influenciadas por ele… apesar do caminho seguido ser totalmente distinto (action based)…
Sobre a Injecao de Dependencias, o conceito tem uma historia bem antiga e interessante… desde o pessoal do extinto Apache Avalon, passando pelo Pico Container, um tempo depois Webwork, Spring, Seam, VRaptor e outros. A lista que começa no webwork sao de controladores web que dão suporte a IoC.
“Batendo cara” com o Pico (depois dele) temos o Spring, o Nano Container, o Plexus (bem mais complexo), o Guice e outro projeto que deve aparecer em breve por ai…
