Vraptor 3 - existe algo com ScopeType.FLASH?

Olá,

não existe nada com flash scope ainda no VRaptor3… Mas vai entrar num próximo release…

provavelmente vai ser algo do tipo: se você fizer um redirect via result.use(…).redirect
tudo que foi incluído via result.include vai ser colocado no flash scope…

[]'s

oi lucas!

isso sera 3.0.1 ou 3.1? e ja tem issue?

Já tem issue e tá incluída arbitrariamente pra 3.0.1
talvez não a implementação inteira, mas pelo menos algo flash

mesmo problema aqui?
http://www.guj.com.br/posts/list/141065.java

Lucas, o escopo flash será declarado manual assim como o @ApplicationScoped ou será automatico, nesse caso todos atributos são exportados como FlashScoped?

acho que não dá pra fazer um @FlashScoped pq o Spring e o Pico não tem um escopo desse gênero…

acho que vai ser mais um: o que foi adicionado no result vai como flash se vc fizer um redirect…

lucascs:

acho que não dá pra fazer um @FlashScoped pq o Spring e o Pico não tem um escopo desse gênero…

acho que vai ser mais um: o que foi adicionado no result vai como flash se vc fizer um redirect…

e se não for esse o caso ?? e vc quiser que o objeto sobreviva a duas requisições ?? não vai ter esse suporte ?

Lavieri:

lucascs:

acho que não dá pra fazer um @FlashScoped pq o Spring e o Pico não tem um escopo desse gênero…

acho que vai ser mais um: o que foi adicionado no result vai como flash se vc fizer um redirect…

e se não for esse o caso ?? e vc quiser que o objeto sobreviva a duas requisições ?? não vai ter esse suporte ?

Em que caso você quereria fazer isso, senão um redirect?

como os providers de DI não suportam FLASH scoped, fica BEM complicado de implementar na mão… via result fica bem mais
fácil de implementar, e acho que é suficiente… mas posso ser convencido do contrário

form step por exemplo....

vou exemplificar com VRaptor2 que tem o escopo FLASH

@Component("cadastroSteeps")
public class CadastroSteepsLogic {
   @In
   private DaoFactory daoFactory;

   @In(scope=ScopeType.FLASH,required = false)
   @Out(scope=ScopeType.FLASH)
   private PessoaJuridica pessoaJuridica;


   public void steep1(PessoaJuridica pessoaJuridica) {
      this.pessoaJuridica = pessoaJuridica;
   }
  
   public void steep2(Endereco endereco) {
      this.pessoaJuridica.getEnderecos().add(endereco);
   }

   public void steep3(List<PessoaFisica> contatos) {
      this.pessoaJuridica.getContatos().addAlll(contatos);
   }

   public void steep4(List<PessoaFisica> socios) {
      this.pessoaJuridica.getSocios().addAll(socios);
   }
  
   @Transaction
   public String commit() {
      if (pessoaJuridica != null) {
         daoFactory.getGenericDao().save(pessoaJuridica);
         return "ok";
      } else
         return "invalid";
   }
}

mesmo vale para o escopo Conversation do JBoss, segue a descrição do JBoss

conversation - Aqui está o verdadeiro diferencial do JBoss Seam que agrega valor no desenvolvimento de aplicações Web com JSF. Este contexto permite armazenar objetos que terão um tempo de vida maior que uma requisição (event) e menor que uma sessão (session). Com este contexto se torna possível definir um escopo para objetos que são usados para implementar um fluxo de telas que realizam um "caso de uso" ou "história de usuário". Num Seam Component é possível anotar o início da conversação num método e anotar outro para demarcar o fim da conversação. O curioso deste contexto é que permite abrir várias janelas de browser para uma mesma tela JSF e cada janela representar uma conversação diferente (contexto diferente de objetos) para execução simultânea do mesmo caso de uso. Cada janela é um contexto separado que não influência um outro contexto aberto.

Você consegue fazer isso bem com um bean Session scoped, e métodos de início e fim do cadastro…

@Session
public class CadastroPessoaFisica {
      private PessoaFisica pf;
      public void start() { // chamado no começo do passo1 do cadastro
          pf = new PessoaFisica();
      }
      // métodos pra executar os passos

     public void finish() { // chamado no fim do último passo, logo após salvar a pessoa física
         pf = null;
     }

}

daí vc recebe essa classe no construtor do controller…
[]'s

lucascs:

Você consegue fazer isso bem com um bean Session scoped, e métodos de início e fim do cadastro…

@Session
public class CadastroPessoaFisica {
      private PessoaFisica pf;
      public void start() { // chamado no começo do passo1 do cadastro
          pf = new PessoaFisica();
      }
      // métodos pra executar os passos

     public void finish() { // chamado no fim do último passo, logo após salvar a pessoa física
         pf = null;
     }

}

daí vc recebe essa classe no construtor do controller…
[]'s

é dai o cara sai no meio da pagina, e fica la o objeto atoa na Session…

sem falar que o escopo session é diferente do FLASH, o flash vale para duas requisições, por mais que seja possivel fazer isso via session, Gerenciar esse tipo de coisa deveria ser uma das atribuições do Framework, =/ , na minha visão claro…

start end, faz vc se preucupar com muitos pequenos detalhes, vc acaba tendo que ficar preucupado com a poluição da sessão… seria legal dar uma olhada no código do JBoss, escopo de 2 requisições é uma mão na roda para várias coisas…

as vezes vc não sabe para onde vai redirect, ou as vezes vc quer que o usuário veja algo na pagina seguinte, mas vc não sabe onde ele vai clicar, enfim… são coisas a serem estudadas.

Mas ai vem a pergunta, pq o scopo falsh existia no 2 ? e vcs querem acabar no 3 ?

A gente não quer acabar com o FLASH… a gente só não implementou ainda

suas razões são boas, me convenceu =)

o único problema é que qualquer requisição ajax da sua aplicação estragaria o escopo FLASH… e se o usuário estiver com duas páginas da sua aplicação abertas e navegar nas duas ao mesmo
tempo também…

Não tem muito como prever isso do lado do framework…