Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make filterModel() in MappingJacksonJsonView more lenient [SPR-6470] #11136

Closed
spring-projects-issues opened this issue Nov 29, 2009 · 5 comments
Assignees
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

Oliver Drotbohm opened SPR-6470 and commented

MappingJacksonJsonView has a filter callback used to respect BindingResult configuration applied to the model. It returns a Map<String, Object> and the result of the filtering is directly passed to the underlying ObjectMapper.

It would be cool if it was possible to reduce the return type to Object as it would allow more sophisticated model filtering. E.g. the current implementation always hands a map to the Jackson ObjectMapper, whereas it might be reasonable to just hand a single object to it. With the more lenient signature one could extract the single object from the model and only hand this to Jackson. In case you already return a container object from the list (e.g. to ensure correct list rendering in XML mapping) the JSON result is effectively wrapped twice (the actual container object + the map that results from Spring's model handling)


Affects: 3.0 RC2

Referenced from: commits cc32399

@spring-projects-issues
Copy link
Collaborator Author

Oliver Drotbohm commented

"In case you already return a container object from the list"

... was meant to be "In case you already return a container object from the handler method ..."

@spring-projects-issues
Copy link
Collaborator Author

Arjen Poutsma commented

Done. You can also consider to use @ResponseBody for this purpose.

@spring-projects-issues
Copy link
Collaborator Author

Oliver Drotbohm commented

I took a look at this, but how to use transparent Accept-Header/URL suffix content negotiation then? As I understood it @ResponseBody is not handled in the ContentNegotiatingViewResover, right?

@spring-projects-issues
Copy link
Collaborator Author

Arjen Poutsma commented

Well, it requires a bit more work from your end ;). You can do something like this:

@Controller
public class MyController {

  @RequestMapping("/foo", headers="accept=text/plain")
  @ResponseBody
  public String fooTextPlain() {
     return "Foo Bar";
  }
  
  @RequestMapping("/foo", headers="accept=application/xml")
  @ResponseBody
  public Foo fooTextPlain() {
     // Foo.class is annotated with JAXB2 @XmlRootElement
     return new Foo();
  }
}

It's not as transparent, but gives you a model more similar to JAX-RS, a model which is closer to the metal, so to say. CNVR only gets you so far, but if it works for you, that's great!

@spring-projects-issues
Copy link
Collaborator Author

Oliver Drotbohm commented

I see. The goal I have is to have a single @Controller for non-human acccess to the applications, thus I'd like to keep the controller free from marshlling information as much as possible. But thanks for the example anyway :).

@spring-projects-issues spring-projects-issues added type: enhancement A general enhancement in: web Issues in web modules (web, webmvc, webflux, websocket) labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 3.0 RC3 milestone Jan 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: web Issues in web modules (web, webmvc, webflux, websocket) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

2 participants