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

@ModelAttribute (method level for reference data) default names could be made more useful [SPR-4264] #8942

Closed
spring-projects-issues opened this issue Dec 17, 2007 · 3 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

Tom Mack opened SPR-4264 and commented

AnnotationMethodHandlerAdapter simply calls implicitModel.addAttribute(attrValue) [around line 228] when an explicit value isn't set on the attribute. It is my opinion that one of the following would be more useful:

  1. Determine the attrName from the name of the annotated method. If the method was called getImportantData, the attrName could be set to "importantData". If the method name didn't start with a get/is, the attrName could simple be equal to the method name.

  2. Instead of simply delegating to the ModelMap class, uses its conventions but apply them to the return type of the method. I'm not a huge fan of the getVariableName idea, but it would be more useful if it took into account the declared return type. If I have a method called "List<SomeBaseClass> getImportantData()", the attrName could be "someBaseClassList" (which is better than arbitrarily picking the class of one item in the list).

I like #1, this is what I expected to happen before I tried it. It also seems to follow how @RequestMapping works when no value is declared. But, I can see how #2 is a smaller change from how it currently works.


Affects: 2.5 final

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Thanks for the suggestions!

As of Spring 2.5.1, @ModelAttribute's default attribute names are consistently derived from the declared parameter/return type now. This was arguably a gap before, since this was based on the declared type for @ModelAttribute-annotated method parameters but not for @ModelAttribute-annotated method return types. Only when the declared type is not specific enough (i.e. Object or a non-typed Collection) we'll fall back to introspecting the returned actual value.

Taking the method name into account is not a bad idea either but unfortunately wouldn't be consistent with @ModelAttribute usage at the parameter level. We might nevertheless support this through a customizable flag at the AnnotationMethodHandlerAdapter level (in a later Spring release).

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Juergen Hoeller commented

Note that what we show in the documentation and in the samples is generally @ModelAttribute usage with an explicit attribute name specified. This is certainly the clearest and most obvious variant, guaranteed to be fully forward compatible (even across major revisions). Default attribute name generation is - more or less deliberately - not documented as a first-class option yet.

That said, the default attributes names are convenient, of course... The problem being that different people have different opinions on what the most intuitive default would be. A general problem of conventions, I guess...

Juergen

@spring-projects-issues
Copy link
Collaborator Author

Arnold Smith commented

+1 for method name as default if "name" attribute is missing!

@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 2.5.1 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