You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For Joda Money module, we have the possibility to select the amount representation on module level. Amount representation varies from API to API. In projects that involve integration with many APIs it would be beneficial to allow such selection on field-level. This ticket collects possible approaches.
This has the benefit of leveraging existing annotation related to formatting without the need to introduce a new one.
We will still have to document the behavior of @JsonFormat on Money (de)serializers as it won't be obvious what shapes are supported and what effect they have.
It might be a bit confusing to some, as the annotation doesn't influence the field itself but rather a particular nested property.
It doesn't help with potential further extensions. As an example, the naming of the properties varies from API to API - I've integrated systems with services using currencyCode instead of currency and value instead of amount as the names of the individual properties carrying the monetary amount. If we wanted to allow customization of the names in the future, most likely we wouldn't do that via @JsonFormat annotation but rather a dedicated one.
Introduce dedicated annotation (here: @JsonMoney) allowing selection of amount representation (see comment):
We configure the format the way users might be used to do it.
We are open for further extension (argument with custom property names above).
We have to introduce a new annotation, mention it in README and document in JavaDocs.
We have to modify @JsonFormat just for the sake of passing custom annotations.
Implementation
Regardless of the approach, most likely Contextual(De)Serializer would be used to build the (de)serializer.
Discussion
Do you see some more characteristics of these approaches?
Do you see a clear winner? (I'm slightly leaning towards approach 2)
Of course we don't have to pull the trigger now - might as well keep this open until we have more insights or convictions. Just wanted to write down my thoughts.
The text was updated successfully, but these errors were encountered:
I believe the functionality described in this enhancement (as it's not really an issue) was not part of #17. In the course of #17 only global selection of the amount representation was done, which applies to (de)serialization of all Money fields. This enhancement pertains to the possibility of overriding the global amount representation for any particular Money field. My goal was to discuss possible approaches in order to select the best one and implement it in the future.
Intro
For Joda Money module, we have the possibility to select the amount representation on module level. Amount representation varies from API to API. In projects that involve integration with many APIs it would be beneficial to allow such selection on field-level. This ticket collects possible approaches.
Appoaches
To achieve field-level selection we could:
@JsonFormat
'sshape
(see comment #1 and comment #2):Characteristics:
@JsonFormat
on Money (de)serializers as it won't be obvious whatshape
s are supported and what effect they have.currencyCode
instead ofcurrency
andvalue
instead ofamount
as the names of the individual properties carrying the monetary amount. If we wanted to allow customization of the names in the future, most likely we wouldn't do that via@JsonFormat
annotation but rather a dedicated one.@JsonMoney
) allowing selection of amount representation (see comment):Characteristics:
@JsonFormat
to allow passing (de)serializer-specific annotations (here: via newwith
attribute):Characteristics:
@JsonFormat
just for the sake of passing custom annotations.Implementation
Regardless of the approach, most likely
Contextual(De)Serializer
would be used to build the (de)serializer.Discussion
Do you see some more characteristics of these approaches?
Do you see a clear winner? (I'm slightly leaning towards approach 2)
Of course we don't have to pull the trigger now - might as well keep this open until we have more insights or convictions. Just wanted to write down my thoughts.
The text was updated successfully, but these errors were encountered: