[go: nahoru, domu]

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

@RequestMapping narrowing based on presence of command object [SPR-4368] #9046

Closed
spring-projects-issues opened this issue Jan 21, 2008 · 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
spring-projects-issues commented Jan 21, 2008

Andreas Schildbach opened SPR-4368 and commented

@RequestMapping largely takes the responsibilities of the former AbstractFormController.isFormSubmission().

Unfortunately, I stumbled upon some cases that are not handled yet by @RequestMapping (well).

  1. Mapping only matches if command object is present / not present

I use this frequently if a have a form with http-method GET (e.g. read-only search forms). In this case, I cannot distinguish by method, and I do not want to distinguish by parameter (the naming of the parameters is up to Spring Binding / Tag Library).

  1. Mapping only matches if parameter is not present

Although not needed as urgently as 1), it would make @RequestMappings easier to formulate and a bit more robust. For example, I see some cases where you want a parameter to be present, and on the other related mapping you want the parameter to not be present.


Affects: 2.5.1

Issue Links:

@spring-projects-issues
Copy link
Collaborator Author

Andreas Schildbach commented

  1. Mapping only matches if a certain media type is accepted (via "Accept" header)

See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1

There are two specialities with this narrowing: One is the wildcarding mechanism, which is probably straight forward. The "relative quality factor" (q) requires not terminate matching on the first match, but to look for further matches with a higher quality factor.

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

FYI, the @RequestMapping annotation supports "!myParam" expressions for non-presence of a specific parameter as well now.

I haven't researched options to support your other two suggestions yet.

Juergen

@spring-projects-issues
Copy link
Collaborator Author
spring-projects-issues commented Apr 24, 2009

Arjen Poutsma commented

Matching on headers is supported in M3, through the 'headers' element on @RequestMapping. See #10360.

@spring-projects-issues
Copy link
Collaborator Author

Arjen Poutsma commented

Changed title to reflect the one outstanding feature request in this issue.

@spring-projects-issues
Copy link
Collaborator Author

Arjen Poutsma commented

Most of the features requested in this issue have been resolved.

As for the matching if command object is present or not present, there are a couple of ways around this:

  • You can assign the initial form retrieval to a different URL than the form submittal (i.e. GET /hotels/new or /hotels/edit). This is arguable better from a REST perspective anyway.
  • Your handler method can handle the two cases in one, and just have a conditional if in your handler method, testing whether the submitted form is actually there.

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