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

Content-type filtering in @RequestMapping [SPR-5623] #10294

Closed
spring-issuemaster opened this Issue Mar 26, 2009 · 4 comments

Comments

Projects
None yet
2 participants
@spring-issuemaster
Copy link
Collaborator

spring-issuemaster commented Mar 26, 2009

Arjen Poutsma opened SPR-5623 and commented

It would be useful to customize the view resolution/content negotiation in the @RequestMapping annotation, by picking a response content-type there. Something like:

@RequestMapping(value = "/hotels", contentType="application/pdf")

This contentType would directly influence the View that is picked by the ViewResolver.


Issue Links:

  • #10360 Request header filtering in @RequestMapping

3 votes, 3 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Mar 28, 2009

Grzegorz Borkowski commented

There can be two approaches for this.

  1. Add 'header' field to ReqestMapping annotation, eg.
    @RequestMapping(value = "/hotels", header = "accept=application/pdf")

This is more generic and powerful, because any header can be matched. But the syntax is a bit awkward (perhaps split it into 'header' and 'headerValue' ? header = "accept", headerValue="application/pdf"). And probability of using other headers then content-type is much smaller (though I can imaging usage of accept-language, accept-encoding headers).

2.The one described in original request: add 'contentType' field to annotation:
@RequestMapping(value = "/hotels", contentType="application/pdf")
This is less powerful, but can be more practical in about 80% of cases, as it's cleaner and less error-prone.

Perhaps both can be implemented: contentType and header. ContentType param would have higher priority if both were used on the same annotation and 'header' also targeted content-type.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Apr 21, 2009

Arjen Poutsma commented

I've created a separate issue for the request header filtering (#10360), since that is not really related to response content-type filtering.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Apr 21, 2009

Arjen Poutsma commented

I think that specifying the response content type in the Request Mapping does not make a lot of sense. We might want to introduce another annotation for it, or simply add a content-type property to ModelAndView. So that you would be able to do something like:

@RequestMapping(value = "/something", headers="accept=text/html")
public ModelAndView handleHtml() {
  ModelAndView mav = new ModelAndView();
  mav.setContentType("text/html");
  return mav;
}

Overall, I need to think about this a bit more...

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator

spring-issuemaster commented Jun 23, 2009

Arjen Poutsma commented

After talking this over with Juergen, we don't see what this approach adds to the current way of explicitly picking a View in the handler method. For instance:

@RequestMapping(value = "/something", headers="accept=text/html")
public View handleHtml() {
  // ...
  ModelAndView mav = new ModelAndView();
  mav.setView(new MarshallerView(myMarshaller));
  mav.addObject(myModelObject);
  return mav;
}

In our opinion, this is much clearer and less magical.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment