[VRaptor] - Estou convencido, mas... (-:

Interceptors -Não sei se vc tem como configurar isso neste nivel no VRaptor, mas pode fazer um interceptor e nele pegar o metodo que vai ser executado e fazer essa verficação por exemplo. Eu sei que não é tão pratico mas pode rolar. Outra coisa seria desenvolver algum tipo de plugin para o Vraptor como eles falam no site.

Global Results - Outra vez acho que não tem como configurar isso. Mas vc pode sobreescrever o redirect apontado dos metodos, então pode apontar todos para uma mesma pagina. É apenas um paliativo.

Emissão de Relatórios no Jasperreports - Acho que não rola suporte não.

Alberto

Será mesmo que nenhuma saída nestes aspectos ?

Acho que em relação a pagina de erro, vc tb poderia configurar isso pelo web.xml deixando uma pagina de erro para cada tipo de exception que for gerada ou uma generica o tipo Exception mesmo.

Alberto

Oi Lucas, tudo bem?

Vou tentar responder seus pontos.

Pessoalmente, creio que se todos os métodos fazem parte da mesma classe, isso indica que eles tem algo em comum e não que eles tem algo de diferente. Principalmente no que tange aspectos.

Os interceptadores são caracteristicas adicionadas apos a compilacao do nosso codigo e nada mais assustador do que ter métodos diferentes em uma mesma classe que possuem características diferentes quando deveriam ter coisas em comum. Creio que nesses casos o ideal seria estarem em classes diferentes.

De qualquer maneira, essa é uma feature comumente pedida, podemos implementar se percebemos a real necessidade dele. Você tem um caso em que realmente faça sentido a intercepção de método diferencial?

Se o forward é em relação a erros, o java ee já definiu isso no web.xml, conforme o Alberto falou:

<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/erro.jsp</location>
</error-page>

Tentamos o caminho mais simples: não reinventar aquilo que já existe o suporte pelo java ee.

Infelizmente não… mas nada que um belo plugin não resolva. Que tal dar mais detalhes ou informações de como funcionaria isso para tentarmos chegar em algo?

Abraço

Guilherme

Olá Guilherme e Lucas,

seguem meus comentários:

Guilherme Silveira:

Pessoalmente, creio que se todos os métodos fazem parte da mesma classe, isso indica que eles tem algo em comum e não que eles tem algo de diferente. Principalmente no que tange aspectos.

Os interceptadores são caracteristicas adicionadas apos a compilacao do nosso codigo e nada mais assustador do que ter métodos diferentes em uma mesma classe que possuem características diferentes quando deveriam ter coisas em comum. Creio que nesses casos o ideal seria estarem em classes diferentes.

De qualquer maneira, essa é uma feature comumente pedida, podemos implementar se percebemos a real necessidade dele. Você tem um caso em que realmente faça sentido a intercepção de método diferencial?

Nesse caso, não é interessante criar uma classe separada para cada método desses(seriam no mínimo 3 classes diferentes com responsabilidades que seriam perfeitamente comportadas em um método de um mesmo componente.

No meu caso, eu resolvi extendendo o servlet do Struts e adicionando uma verificação por annotations. Nós basicamente marcamos o método à ser verificado com @Permission(“cidade (pesquisa)”) por exemplo, e o servlet se encarrega de veriricar na sessão do usuário e redirecionar pra página de acesso negado em caso de erro. Acho que é isso que o Lucas precisa.

Guilherme Silveira:

Se o forward é em relação a erros, o java ee já definiu isso no web.xml, conforme o Alberto falou:

<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/erro.jsp</location>
</error-page>

Tentamos o caminho mais simples: não reinventar aquilo que já existe o suporte pelo java ee.

Abraço

Olá Guilherme e Plentz,

Bom Guilherme, agradeço as respostas, mas vamos lá exatamente ao que quero focar. Quanto a parte de Interceptors por método, seria tal qual o Plentz disse. Bom, basta que imaginemos o JForum que está sendo desenvolvido utilizando VRaptor. Quando logamos, e alteramos nossos dados pessoais, acredito que ele irá trabalhar com o componente “user” fazendo algo como user.save.logic, correto? Esta ação tem que ser monitorada em questões de permissões (pra começar, se realmente o neguinho tá logado). Mas como fazer a listagem de membros (http://www.jforum.net/user/list.page) que não pede para o usuário estar logado? Seria a user.list.logic, porque acredito trabalhar com o mesmo componente “user” mas não com a mesma validação. Não me sentiria confortável tendo um componente “user” e outro “userAdm” apenas para restringir acesso a alguns determinados métodos.

Outro ponto aí é a questão de que cada requisição deve ter a flexibilidade individual para seus Filters/Interceptors, usando outro exemplo, tenho algumas requisicoes (geralmente com formulários) que requerem um Token Interceptor, agora adicionar um deste para uma requisição de listagem seria desnecessário não é? São estas questões que tento mostrar.

Acredito que a tag @InterceptedBy em nível de classe funciona muito bem quanto a ser uma alternativa para o “default interceptor” para um determinado package dentro de um mapeamento xwork do WW, funciona como padrão para todas as actions ali dentro descritas (no caso, todos os metodos desta classe), porém caso eu quisesse ‘mudar’ estes interceptadores para uma determinda action (método no vraptor) eu poderia adicionar a @InterceptedBy ali…

Consegui explicar? (-:

Bom, quanto ao Global Result, entendo a saída adotada no caso da exception ser capturada em ‘ultimo nível’ e mapeado seu direcionamento no xwork, porém mesmo assim, acredito que seria legal ter alternativas para isto, eu utilizo um global result não só para o retorno “ERROR”, quanto para o retorno “EXCEPTION” quanto até para o “SUCCESS”, pois em caso de não existir, acesso este default.

E quanto ao Jasper, talvez um plugin coubesse ali, mas o Result que funciona no webwork também é bem interessante, todos os parametros recebidos no request, são mapeados e enviados para o Jasper. Algo simples, mas que economiza muito tempo e alguns cabelos.

(-:

Obrigado pessoal,

Se a intercepcao eh para fazer sistema de autorizacao basta vc fazer um plugin que verifica todos os componentes e intercepta aqueles anotados. É exatamente isso que eu faço tambem em meus projetos, mas nao precisa estender a servlet do struts - no nosso caso - :), basta criar um interceptador ou um plugin.

O redirecionamento pode ser feito para:

<location>/minhalogicabonitadetratamentodeerro.logic</location>

E voce pode se divertir enviando emails

Oi Lucas, vou primeiro dar a solucao, que o proprio Plentz ja apresentou:

Lucas Teixeira:

Não me sentiria confortável tendo um componente “user” e outro “userAdm” apenas para restringir acesso a alguns determinados métodos.

A solucao e utilizar o interceptador para a classe e so intercepte os metodos anotados com @Role(“algumaCoisa”).

A explicacao foi clara na primeira mensagem

Basta voce escrever seu proprio ViewManager que implementa a funcionaliade que voce deseja (veja a interface ViewManager) e seta-lo em seu vraptor.xml.
Podemos criar um ViewManager que saiba interpretar determinados valores padrao. Como funcionaria?

Sem problemas, pode montar um exemplo do que queria que funcionasse? (codigo mesmo)

Tanto no caso do view manager quanto no jasper, podem ser funcionalidades a serem adicionadas opcionalmente pelo usuario que podemos implementar, creio que vale a pena discuti-las em mensagens separadas nessa mesma thread so para que cada mensagem nao fique muito grande, pode ser?

Abraco

Guilherme

Ps parenteses: pessoalmente (vejam bem, pessoalmente), ainda nao gosto de colocar metodo list e metodo save na mesma classe:

public class UserComponent {

  private List users;

  // + o getter

  public void save(User user) {
    // codigo para adicionar
  }

  public void list() {
    this.users = // codigo para listar;
  }
}

Pergunta 1: Agora imagine a logica de adicionar usuarios funcionando. Ai voce pega um programador sem muita experiencia que apos adicionar o usuario tenta usar ${users}… o que acontece? Vem vazio em vez de vir de outro lugar qualquer que ele esperava. Pq?

Resposta suspeita 1: Pq a classe de adicionar um usuario possui um metodo chamado getUsers() que nao deve ser chamado.

Pergunta 2: O que a logica de listar usuario e adicionar usuario tem em comum?

Resposta suspeita 2: a palavra usuario.

Pessoalmente, toda classe (em qualquer linguagem) que possui um metodo que nao deve ser chamado tem algo de muito estranho em sua construcao. Toda classe que junta metodos que em comum só tem o nome, e não o comportamento, não pertencem ao mesmo grupo.

Importante: essa é minha opiniao pessoal. Gosto é gosto, eu sei. Eu não abomino colocar os metodos juntos, mas acho estranho uma lógica ter métodos que não fazem sentido em determinados casos. Funcionando, terminando o projeto e todo mundo saindo feliz é o que importa.

Trabalho começado no interceptador, voce pode testar o andamento (que pode ja estar funcionando nesse instante) baixando o vraptor do cvs e fazendo o build.

O plugin é org.vraptor.plugin.interceptor.MethodInterceptorPlugin

Basta registra-lo no vraptor.xml (arquivo opcional a ser colocado no classpath).

So nao sei ainda se tal funcionalidade entra no core (isto é, sem plugin algum).

Acompanhamento: http://jira.vraptor.org/browse/VRA-344

Abraço

Guilherme

Se a intercepcao eh para fazer sistema de autorizacao basta vc fazer um plugin que verifica todos os componentes e intercepta aqueles anotados. É exatamente isso que eu faço tambem em meus projetos, mas nao precisa estender a servlet do struts - no nosso caso - :), basta criar um interceptador ou um plugin.

Yup. Mais fácil e mais decente

O redirecionamento pode ser feito para:

<location>/minhalogicabonitadetratamentodeerro.logic</location>

E voce pode se divertir enviando emails :)

Ops :oops:

dahora o vraptor caras, é bem legal mesmo!! =)
o foda é q eu ja to estudando tantos frameworks, se eu for colocar mais esse vou ficar ainda mais perdido

abracos, e continuem assim

Ressucitando o Tópico…

O Guilherme disse:

Bem… Como eu faria isso? Pelo que estudei no código, e procurando na net, não tem como criar um ViewManager e seta-lo pelo vraptor.xml

Eu ja criei meu ViewManager mas não sei como colocar no sistema. To quase pegando o código fonte todo do vRaptor e colocar junto com o sistema, trocando o RegexViewManager pelo viewManager que eu fiz.

Agradecido

Everton Tavares

Ressucitando o tópico… ainda sim acho mais elegante um exception handler, assim como era no struts1. Pois dessa forma era possível eu “interceptar” o erro, tratar e a partir daí fazer algum redirecionamento.

Um exemplo eram os cruds, onde eu poderia fazer a página de store ir para a página de edit quando um erro ocorria, ou então no edit caso desse um erro de permissão eu redirecionava para a tela de listagem e exibia uma mensagem de erro.