Uma das vantagens de utilizar a arquitetura do Spring para implementar projetos Web, é fazer uso do Sprin-WEB-MVC. Quem já usou sabe que isso é uma vantagem a se considerar quando for feita a escolha das tecnologias e frameworks que serão utilizados no projeto.
Spring WEB-MVC é uma abstração poderosa para a camada de apresentação, tornando muito flexível o uso de diferentes tipos de tecnologias no frnt-end da aplicação.
Veremos uma dessas abstrações que ajudam a modularizar e simplificar nosso trabalho do lado do servidor: Views.
Conceito de Views
Toda requisição que segue para o WEB-MVC passa pelo DispatcherServlet do spring. A partir daí, o container se responsabiliza por delegar a chamada para o controller correto, baseando-se nas configurações de sua aplicação.
Depois que a chamada é tratada pelo controller, o spring manda a resposta correspondente atrelada a uma View. Uma View é um descritor da forma com que os dados vão ser apresentados na interface, podendo ser JSP, JSF, JSon, XML, etc., ou até mesmo uma forma de encapsular os dados específica da sua aplicação.
O poder das Views está justamente no fato de ser apenas uma descrição de como os dados serão apresentados, portanto desconecta-se completamente da aplicação, e pode ser aproveitada em outras ocasiões por outros sistemas.
Uma View no Spring nada mais é do que uma interface Java que descreve o tipo do conteúdo, e é responsável por renderizar a requisição:
[cc lang=”java” width=”100%”]
/*
* Copyright 2002-2008 the original author or authors.
*
* Licensed under the Apache License, Version 2.0 (the “License”);
* you may not use this file except in compliance with the License.
* You may obtain a copy of the License at
*
* http://www.apache.org/licenses/LICENSE-2.0
*
* Unless required by applicable law or agreed to in writing, software
* distributed under the License is distributed on an “AS IS” BASIS,
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
* See the License for the specific language governing permissions and
* limitations under the License.
*/
package org.springframework.web.servlet;
import java.util.Map;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
/**
* MVC View for a web interaction. Implementations are responsible for rendering
* content, and exposing the model. A single view exposes multiple model attributes.
*
*
This class and the MVC approach associated with it is discussed in Chapter 12 of
* Expert One-On-One J2EE Design and Development
* by Rod Johnson (Wrox, 2002).
*
*
View implementations may differ widely. An obvious implementation would be
* JSP-based. Other implementations might be XSLT-based, or use an HTML generation library.
* This interface is designed to avoid restricting the range of possible implementations.
*
*
Views should be beans. They are likely to be instantiated as beans by a ViewResolver.
* As this interface is stateless, view implementations should be thread-safe.
*
* @author Rod Johnson
* @author Arjen Poutsma
* @see org.springframework.web.servlet.view.AbstractView
* @see org.springframework.web.servlet.view.InternalResourceView
*/
public interface View {
/**
* Name of the {@link HttpServletRequest} attribute that contains the response status code.
*
Note: This attribute is not required to be supported by all
* View implementations.
*/
String RESPONSE_STATUS_ATTRIBUTE = View.class.getName() + “.responseStatus”;
/**
* Return the content type of the view, if predetermined.
*
Can be used to check the content type upfront,
* before the actual rendering process.
* @return the content type String (optionally including a character set),
* or null if not predetermined.
*/
String getContentType();
/**
* Render the view given the specified model.
*
The first step will be preparing the request: In the JSP case,
* this would mean setting model objects as request attributes.
* The second step will be the actual rendering of the view,
* for example including the JSP via a RequestDispatcher.
* @param model Map with name Strings as keys and corresponding model
* objects as values (Map can also be null in case of empty model)
* @param request current HTTP request
* @param response HTTP response we are building
* @throws Exception if rendering failed
*/
void render(Map
}
[/cc]
Todo o código e JavaDoc está no projeto do Spring.
JSon e XML
Vamos criar um exemplo de controller com duas views diferentes: JSon e XML. JSon e Xml são os formatos mais comuns na Web, por isso vamos ver uma das maneiras de devolvê-las em nossos contrllers.
Não vou entrar no detalhe de como configurar os controllers da sua aplicação para funcionar com o Spring-WEB-MVC, pois não é o intuito deste post, e existe bastante documentação disponível na internet sobre o assunto.
A maneira que escolhi para o exemplo, foi deixar a resposta padrão da servlet como XML, e criar uma alternativa de view em JSon. Você pode configurar como quiser a ordem e o padrão de view da sua aplicação, essa escolha serve apenas para ilustar como lidar com os dois casos.
Comece criando alguma classe de domínio para servir de resposta do nosso controller:
[cc lang=”java” width=”100%”]
public class Exemplo {
private String nome;
public String getNome() {
return nome;
}
public void setNome(String nome) {
this.nome = nome;
}
}
[/cc]
Agora vamos criar um Controller para devolver nosso objeto de domínio:
[cc lang=”java” width=”100%”]
@Controller
public class ExemploController {
@RequestMapping(“/exemplo/xml”)
@ResponseBody
public Exemplo testando() {
Exemplo ret = new Exemplo();
ret.setNome(“xml”);
return ret;
}
}
[/cc]
Agora temos uma servlet que responderá por “
Vamos configurar agora nosso ‘empacotador’ de XML para torná-lo formato padrão da aplicação. No arquivo de beans do Spring crie os seguintes beans:
[cc lang=”xml” width=”100%”]
[/cc]
O que fizemos foi criar um “marshaller” de XML que usa o XStream para converter ‘de’ e ‘para’ XML. Também mapeamos nossa classe de domínio para o alias “exemplo”. Feito isso basta criar um bean que representa os conversores de mensagens do Spring, nesse caso ‘messageConverters’, e associar o conversor de XML nele.
Pronto! Agora que temos as configurações necessárias para criar XML, e anotamos nosso método do controller com ‘@ResponseBody’, o padrão do Spring será devolver o XML que representa a entidade de domínio criada:
[cc lang=”xml” width=”100%”]
[/cc]
Para criar a view de JSon agora, vamos fazer de maneira diferente. Comece criando um bean em seu arquivo do Spring que representa a View de JSon:
[cc lang=”xml” width=”100%”]
[/cc]
Note que precisamos da dependência do ‘Jackson’ no classpath do nosso projeto, que está disponível no site do projeto ou até mesmo no repositório do maven.
Agora em nosso controler, vamos adicionar a dependência da view que acabamos de criar, e adicionar o método que tratará a requisição em JSon:
[cc lang=”java” width=”100%”]
private View jsonview;
@Autowired
@Qualifier(“jsonview”)
public void setJsonview(View jsonview) {
this.jsonview = jsonview;
}
@RequestMapping(“/exemplo/json”)
public ModelAndView testandoJson() {
Exemplo ret = new Exemplo();
ret.setNome(“json”);
return new ModelAndView(this.jsonview, “response”, ret);
}
[/cc]
Repare que não precisamos da anotação ‘@ResponseBody’, e que ao invés de devolver um ‘Exemplo’ estamos devolvendo o ModelAndView do SpringWEBMVC.
Para que a resposta chegue no formato correto, basta mandar a view de JSon que criamos junto com o ModelAndView, e o objeto de domínio. Dessa forma temos a resposta que esperamos:
[cc lang=”xml” width=”100%”]
{“response”: {
“nome”:”json”
}
}
[/cc]
Conclusão
Para a moda REST que está tomando força nos últimos tempos, as múltiplas views do Spring é uma ótima ferramenta para fazer parte dessa onda, e ainda prover diferentes maneiras de seu servidor se comunicar com diversos tipos de dispositivos e aplicações clientes, sem comprometer código com regras de negócio.
Espero ter sido útil, e qualquer dúvida, crítica ou comentário são sempre bem vindos.
Por @Gust4v0_H4xx0r
Compartilhe isso:
