VRaptor 3 vs VRaptor 2

Assuntos Gerais
#1

Estou com a seguinte duvida o vraptor-3 nao tem o mesmo comportamento que vraptor-2 em parte de receber dados do cliente

exemplo VRaptor-2

@Component
public class TestController {
	@Out
	private CadRamo cadramo;
	
	public void salvar() {
		// TODO Auto-generated method stub
		System.out.println("cadramo:" + cadramo.getDescricao());
		formulario(cadramo);
	}
	
	public CadRamo getCadramo() {
		return cadramo;
	}
	public void setCadramo(CadRamo cadramo) {
		this.cadramo = cadramo;
	}
}

Aqui o cadramo vai ser populado

exemplo VRaptor-3

@Resource
public class TestController {
	private CadRamo cadramo;
	
	@Post
	public void salvar() {
		// TODO Auto-generated method stub
		System.out.println("cadramo:" + cadramo.getDescricao());
		formulario(cadramo);
	}
	
	public CadRamo getCadramo() {
		return cadramo;
	}
	public void setCadramo(CadRamo cadramo) {
		this.cadramo = cadramo;
	}
}

Aqui ja o cadramo não vai ser populado.

Teria como VRaptor-3 ter o mesmo comportamento que VRaptor-2 nesta parte.

Obrigado !!!
JVDS

#2

No Vraptor 3 você não precisa ter getters nem setters. Tudo é feito via injeção no construtor.

Outra diferença que no Vraptor 2 você precisa anotar uma propriedade como @Out para que ela esteja disponivel na sua tela. Já no Vraptor 3 você pode usar o result.include.

#3

[quote=garcia-jj]No Vraptor 3 você não precisa ter getters nem setters. Tudo é feito via injeção no construtor.

Outra diferença que no Vraptor 2 você precisa anotar uma propriedade como @Out para que ela esteja disponivel na sua tela. Já no Vraptor 3 você pode usar o result.include.
[/quote]

Ok ate ai eu sei so nao estou tendo uma idea de como nao precisar declarar em cada metodo um parametro e sim declarar este objeto deixando ele publico para todos estes meus metodos .

Não sei se fui muito claro.

Obrigado !!!
JVDS

#4

Minha opinião: faça os objetos estarem sempre no nível mais baixo de onde você precisa. Ou seja, declare sempre o objeto no método, e se outro método precisar passe-o como parametro. Penso que assim fica mais simples de organizar e visualizar os métodos, além de que fica mais simples reaproveitar os métodos.

[code]public class MeuController {

public void foo(MeuObjeto instancia) {
    bar(instancia);
}

public void bar(MeuObjeto instancia) {
    System.out.println(instancia);
}

}[/code]

Mas se você quer mesmo usar os objetos na classe, pode fazer algo assim:

[code]public class MeuController {

private MeuObjeto instancia;

public void foo(MeuObjeto instancia) {
    this.instancia = instancia;
}

public void bar() {
    System.out.println(instancia);
}

}[/code]

#5

[quote=garcia-jj]Minha opinião: faça os objetos estarem sempre no nível mais baixo de onde você precisa. Ou seja, declare sempre o objeto no método, e se outro método precisar passe-o como parametro. Penso que assim fica mais simples de organizar e visualizar os métodos, além de que fica mais simples reaproveitar os métodos.

[code]public class MeuController {

public void foo(MeuObjeto instancia) {
    bar(instancia);
}

public void bar(MeuObjeto instancia) {
    System.out.println(instancia);
}

}[/code]

Mas se você quer mesmo usar os objetos na classe, pode fazer algo assim:

[code]public class MeuController {

private MeuObjeto instancia;

public void foo(MeuObjeto instancia) {
    this.instancia = instancia;
}

public void bar() {
    System.out.println(instancia);
}

}[/code][/quote]

No 2 caso que voce me mostrou e que eu quero fazer sim mas se eu executar primeiro metodos /meu/foo ele vai guardar o valor do objeto, mas se executar depois /meu/bar ele vai perder o valor vou receber null exception.

#6

Só vai perder se forem requisições diferentes. Como o ciclo de vida dos objetos são request, obviamente você vai perder os dados da requisição anterior.

O que você está pensando em fazer é algo como o Conversation do JBoss Seam? Caso sim, o mais proximo disso no Vraptor é usar o teu controller como @SessionScoped.

#7

se o controller for @SessionScoped vc não pode usar Result nele…

o ideal é ter outra classe que seja @SessionScoped e usá-la pra isso…

vc precisa disso pra conversation mesmo? ou é só pra economizar código?

#8

Sim a para conversation mesmo.

#9

cria uma classe:

@Component
@SessionScoped
public class CadRamoSteps {
    private CadRamo cadRamo;

    public CadRamo getCadramo() {  
        return cadramo;  
    }  
    public void setCadramo(CadRamo cadramo) {  
        this.cadramo = cadramo;  
    }  
}

e receba-a no construtor do controller…

o ideal é vc não usar o getter e setter, mas colocar métodos mais representativos, do tipo:
-criaCadRamo
-preencheBolinha(x,y,z);
-preencheQuadrado(a,b,c);
-salva

assim esse CadRamoSteps seria tipo um builder de CadRamo

#10

[quote=Lucas Cavalcanti]cria uma classe:

@Component
@SessionScoped
public class CadRamoSteps {
    private CadRamo cadRamo;

    public CadRamo getCadramo() {  
        return cadramo;  
    }  
    public void setCadramo(CadRamo cadramo) {  
        this.cadramo = cadramo;  
    }  
}

e receba-a no construtor do controller…

o ideal é vc não usar o getter e setter, mas colocar métodos mais representativos, do tipo:
-criaCadRamo
-preencheBolinha(x,y,z);
-preencheQuadrado(a,b,c);
-salva

assim esse CadRamoSteps seria tipo um builder de CadRamo[/quote]

E eu tinha pensado nisso mas e que isso nao e muito elegante estou certo disso ?

#11

se a classe for só o getter e setter não é elegante mesmo…
mas se vc fizer como eu te falei e colocar métodos mais representativos fica bastante elegante

pensa por enqto q esse CadRamoSteps vai ter um método pra cada lógica do controller e no final ela retorna o cadRamo preenchido totalmente, pronto pra salvar

#12