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

No way to register Formatter instances by field on DataBinder [SPR-6069] #10737

Closed
spring-issuemaster opened this issue Sep 2, 2009 · 7 comments

Comments

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

commented Sep 2, 2009

Keith Donald opened SPR-6069 and commented

On DataBinder, I see you can call getFormatterRegistry().add(...). However, there is no specific binder.registerFormatter(String, Formatter<?>) callback that allows you to register a Formatter for a specific field, as an alternative to binder.registerCustomEditor(Class, String, PropertyEditor).


Affects: 3.0 M4

Issue Links:

  • #10839 "Registering field-specific Formatters" section is not in sync with the codebase
  • #10684 Add Formatter support to DataBinder
  • #12429 Provide a formatter registry capability local to a controller

Referenced from: commits 02da2e8

9 votes, 10 watchers

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 13, 2010

Oliver Drotbohm commented

This one seems to be a crucial thing for us to migrate to the new infrastructure as we thend to use domain objects in the controllers as well and do not want them to be polluted with UI specific annotations.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Mar 16, 2011

Keith Donald commented

i get what you're after.
[3/16/11 4:14:19 PM] Keith Donald: my goal has been to have stateless formatters that are configured once and can be parameterized at format time (typically via @Format annotaiton metadata)
[3/16/11 4:14:43 PM] Keith Donald: in this way there's rarely the need for a user to register custom formatters themselves in @InitBinder
[3/16/11 4:14:49 PM] Keith Donald: and that's a nice simplificaiton.
[3/16/11 4:15:05 PM] Keith Donald: in your case though, you'd like to bind directly to a domain object and not couple that object with a specific format annotation.
[3/16/11 4:15:19 PM] Keith Donald: so you'd need an extenrnalized mechanism for expressing the same field formatting rule.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 22, 2012

Donnchadh O Donnabhain commented

Any further thoughts on this and #12429?

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 23, 2012

Burkhard Graves commented

Yes, I wonder too. Moreover, this seems to be related to #10684 and #10839 - and both tasks are marked as 'solved'?! I don't get it...

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 23, 2012

Donnchadh O Donnabhain commented

I think #10839 was fixed by removing the "Registering field-specific Formatters" section.
As you point out #10684 references DataBinder.getFormatterRegistry() which doesn't seem to exist.

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 23, 2012

Burkhard Graves commented

Ah, ok, now I understand why #10839 was closed (by the way, I found http://static.springsource.org/spring/previews/ui-format.html#ui-format-registering-field-specific-Formatters - should be better removed by the spring team, I think ;-)).

But I still don't understand why #10684 was closed...

@spring-issuemaster

This comment has been minimized.

Copy link
Collaborator Author

commented May 12, 2015

Juergen Hoeller commented

I'm introducing addCustomFormatter(Formatter formatter, String... fields) and addCustomFormatter(Formatter formatter, Class... fieldTypes) to DataBinder, internally adapting the given Formatter to a PropertyEditor and registering that adapter with the underlying PropertyEditorRegistry, following the usual rules there. This is a quite simple and straighforward approach which should hopefully cover the typical use case here, without having to build an extra local ConversionService underneath the covers.

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.