-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Add support for annotation-based integration with attributes (see #319) #322
Comments
Does it make sense having a feature to bind all "current" POJO's automatically? I am referring "Person" in your example by "current". |
That was one possibility I was thinking. I think could go along with attribute, so there could be one-offs as well as "just bind them all". Can you file a request for adding such a feature? I am trying to close 2.3, so it could go in 2.4. |
FWTW, while this has not been implemented, the idea of "decorating" output is still very much alive. |
Created a new issue, #638, to extend a bit; closing this one (also, easier to see one that's more recent). |
After addition of per-call (context) attributes, one possible next step is to allow annotation-based way to "bind" attribute values to/from incoming JSON.
These could be indicated by new annotation(s); for example, hypothetical
@JacksonAttribute
annotation (not "Json" since this specific to Jackson library, not data-binding or JSON).First possible feature is that of binding "current" POJO as an attribute; so that when reading or writing JSON, currently processed object could be set as value of specified attribute. This could be done on per-class basis (for all values that are instances of the class), or per-property (POJO value of the property).
This could be controlled separately for serialization and deserialization. For example:
this would be most useful for custom (de)serializers: a commonly occurring example is that where child value (say "Address" here) would need access to its "parent" (Person in this case). With this annotation we could automate assignment of attribute, to be accessible from the custom serializer.
Another feature that could be useful is automatic addition of "virtual" properties: we could indicate that value(s) of specified attribute(s) should be added as if they were regular properties. Something like:
which means that "take value of attribute with key
id
and serialize it as if there was a property named "id".I will need to think about whether to tackle this now for 2.3, or postpone; most likely it should wait so that we can finalize 2.3 first, with first take on attributes.
The text was updated successfully, but these errors were encountered: