@Remotable + VRaptor 3 no more?

Pela documentação você escreve seu método normal, e pelo padrão quando no request vier um header requisitando json o vraptor vai trazer como json. Você só precisa fazer um JSP com o padrão logic.json.jsp.

Na classe br.com.caelum.vraptor.view.DefaultAcceptHeaderToFormat:

map.put("text/html", "html");
map.put("application/json", "json");

E na classe br.com.caelum.vraptor.view.DefaultPathResolver

public String pathFor(ResourceMethod method) {
	String acceptedHeader = request.getHeader("Accept");
	String format = "html"; 
		
	if (acceptedHeader != null)
		format = acceptHeaderToFormat.getFormat(acceptedHeader);
		
	String formatParam = request.getParameter("_format");
	if (formatParam != null)
		format = formatParam;
		
	String suffix = "";
	if (format != null && !format.equals("html")) {
		suffix = "." + format;
	}
        String name = method.getResource().getType().getSimpleName();
        String folderName = extractControllerFromName(name);
		return getPrefix() + folderName + "/" + method.getMethod().getName() + suffix
				+ "."+getExtension();
}

gostava da anotação q fazia as coisas pra mim =[ … so definia o deep e era feliz…

sem falar que fiz uns utilitarios =/ … pra transformar objetos java em JSON value, text para montar Selects =[

T_T

Eu estou fazendo uns testes aqui com alguns componentes que fiz para minha aplicação com vraptor3, e conforme vou documentando estou enviando para o Lucas para colocar num cookbook. Converse com ele e envie os seus.

esse é sem duvida um ponto de melhoria pro vraptor3. queremos algo mais facil ainda, talvez um result…
sugestoes sao bem vindas!

Olá…

a funcionalidade de gerar o json não foi implementada ainda, mas vai =)

pode ser tanto algo como:

result.include("usuario", usuario);
result.use(json()).depth(2).exclude("usuario.roles").exclude("usuario.senha");

ou se você passar _format=json ou o header Accepts=application/json,
o vraptor pegar tudo que foi incluido no result e fazer a conversão pra JSon de tudo…

tem alguns problemas nisso… mas o que vcs acham?

lucascs:

Olá…

header Accepts=application/json,
o vraptor pegar tudo que foi incluido no result e fazer a conversão pra JSon de tudo…

tem alguns problemas nisso… mas o que vcs acham?

Acho bem interessante, tanto q estava implementado algo nesse sentido, hehehe

[]s

lucascs:

Olá…

a funcionalidade de gerar o json não foi implementada ainda, mas vai =)

pode ser tanto algo como:

result.include("usuario", usuario);
result.use(json()).depth(2).exclude("usuario.roles").exclude("usuario.senha");

ou se você passar _format=json ou o header Accepts=application/json,
o vraptor pegar tudo que foi incluido no result e fazer a conversão pra JSon de tudo…

tem alguns problemas nisso… mas o que vcs acham?

Como sempre soluções elegantes. Mas qual seria o problema que você citou? O bom que dá para ao mesmo tempo fazer xml e json, já que o xstream por exemplo faz o output com ambos usando jetinson.

garcia-jj:

Como sempre soluções elegantes. Mas qual seria o problema que você citou? O bom que dá para ao mesmo tempo fazer xml e json, já que o xstream por exemplo faz o output com ambos usando jetinson.

se for fazer automaticamente a conversão pra json e xml, como definir a profundidade? navegar em toda a árvore de objetos?
como excluir determinadas propriedades?

lucascs:

ou se você passar _format=json ou o header Accepts=application/json,
o vraptor pegar tudo que foi incluido no result e fazer a conversão pra JSon de tudo…

tem alguns problemas nisso… mas o que vcs acham?

isso tem problemas graves de seguranca. alias foi boa parte o motivo do @Remotable ter sido tirado no vraptor3.
o grande problema eh que result.include eh para mandar objetos pra view: um redirect interno no servidor. imagina se o cliente puder acessar todos os meus objetos simplesmente colocando _format=json

exemplo classico: uma pg de boas vindas de login onde quero mostrar “Bem vindo ${usuario.nome}” entao faço result.include(usuario).
se o cara passar _format=json ele poderá ver usuario.senha etc?

eu sou dos que nao gostava do @Remotable por sua potencial inseguranca (se bem que nesse caso eh menos pior pq o programador tem que liberar acesso ao metodo com a anotacao, nao basta só mudar o accepts). na epoca eu e o kung discutimos isso e decidimos deixar de fora do vr3 ate encontrarmos uma solucao que fosse ao mesmo tempo simples e segura.

eu acho complicado isso de misturar logicas… uma mesma logica servir para redirecionar pra view e pra retornar json pro cliente.
preferia que fossem 2 metodos diferentes. e de algum jeito fazer isso facil.
a solucao do jax-rs com @Produces(“app/json”) me parece algo mais interessante. ou entao um metodo q retorne JSonObject… sei la

Sérgio, boa opinião. Aliás eu poderia jurar que ví nos fontes pré-release do vr3 (posso chamar assim?) essa annotation @Produces. Inclusive a impressão que eu tinha era que teria isso. Ou me confundi com algum outro framework. Acho que um @Produces seria elegante, porém uma mais uma annotation. Me parece que o JsonObject parece mais interessante, já que por padrão o vraptor usa isso para jogar os dados na tela.

Oi pessoal

Estou anotando diversas das ideias na issue que ja esta aberta a respeito: