Bem… andei dando uma sondada na documentação do VRaptor 3 e descobri que ele oferece um recurso que permite a criação de rotas genéricas em tempo de execução, mas infelizmente a documentação está muito enxuta. Alguém teria mais alguma informação a respeito?
mas nessa parte está praticamente tudo o que você pode usar…
tente navegar nos métodos possíveis a partir do
routeFor("/…/…")
você pode colocar variáveis (templates) nas URIs, bastando
colocá-las entre chaves ({}), você pode adicionar restrições via espressões regulares com withParameter(…).matching(regex), e adicionar prioridades pras rotas com o withPriority… trocar o HTTP method com with(HttpMethod)
não tem muita documentação sobre isso, pq a gente não quer que
você precise usar essa classe, a anotação @Path no método deveria ser suficiente…
tem algo que você queira fazer que não está na documentação, ou não dá pra fazer com o @Path?
[]'s
fahecon
Porque minha idéia é trabalhar sobre um único controller genérico, onde todas as outras especialistas a herdaram e se necessário, uma sobrecarga de um método nessa Classe especialista resolveria.
Mas ai entra a questão das rotas, como deixar as rotas genéricas também? A ponto de dinamicamente ter a mesma flexibilidade.
Não sei se fui muito claro.
[ ]'s
Fábio Heleno
Lucas_Cavalcanti
se o que você quer dizer com rotas genéricas, é sobrescrever a convenção de URIs do VRaptor ( /<controller_name>/ ), você pode criar a seguinte classe:
Não precisa configurar nada em lugar nenhum, é só criar essa classe…
isso é suficiente? se não for, você pode falar o caso em que isso não funciona?
[]'s
fahecon
Opa Lucascs.
Até entendi o escorpo, mas não a aplicabilidade disso.. na pratica não consegui visualizar... até tentei implementar, vejo que a classe é chamada quando o projeto é iniciado, mas após inicio da aplicação não ocorre mais nenhuma chamada a esta classe.
Fora que minha aplicação parou de funcionar quando ponho essa classe rodando.
Qual procedimento estaria faltando adotar para que isso funcione?
[ ]'s
Fábio Heleno
G
garcia-jj
fahecon:
Qual procedimento estaria faltando adotar para que isso funcione?
[ ]'s
Fábio Heleno
Você deve implementar sua lógica onde possui os comentários //sua convenção aqui
fahecon
Pois é Garcia, mas não há nada na documentação que me diga quais as possibildiades de trabalho nesta classe, nenhuma referencia… dai fica dificil ficar aqui na base do chutometro.
Mas é exatamente o ponto que você levantou é o que preciso de esclarecimentos… preciso compreender melhor a execução disto.
[ ]'s
Fábio Heleno
G
garcia-jj
fahecon:
Pois é Garcia, mas não há nada na documentação que me diga quais as possibildiades de trabalho nesta classe, nenhuma referencia… dai fica dificil ficar aqui na base do chutometro.
Mas é exatamente o ponto que você levantou é o que preciso de esclarecimentos… preciso compreender melhor a execução disto.
[ ]'s
Fábio Heleno
Fábio, a documentação ainda está clean. Por enquanto eu estou analisando os fontes dos componentes e assim criando meus componentes com base nesses. Por exemplo, semana passada fiz um TilesPathResolver, então me baseei no que está padrão no vraptor. Os códigos me pareceram muito simples de entender, bem documentado via javadoc, além de bem intuitivos.
Uma coisa que acho interessante, já que a doc está curta ainda, é trocarmos as nossas idéias aqui e aos poucos enviando essas sugestões e até mesmo textos nossos para incluir na documentação. Eu estou com uma série de componentes e afins que fiz, e quero assim que conseguir documentar enviar para análise do pessoal do vraptor.
bom, pra ficar mais claro… a convenção para URIs é:
/<controller_name>/<method_name>
se você quiser mudar a convenção do controller_name, você sobrescreve o método extractControllerName e retorna qual é a convenção. por exemplo se vc quiser remover o sufixo “Logic”:
se você quiser sobrescrever a convenção /<controller_name>/<method_name> para /<controller_name>.<method_name>.logic é só sobrescrever o método defaultUriFor: