-
Notifications
You must be signed in to change notification settings - Fork 12
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
Support for star-like writable fields #44
Comments
This goes to 1.0.0 because requires backwards incompatible changes. |
swistakm
added a commit
that referenced
this issue
Apr 10, 2017
* remove `source="*"` handling * move instance/representation manipulation responsibility to field objects to support nested objects and multiple key access pattern * update docs * fix #44 (writable star-like fields) * fix #43 (broken resource manipulation on star-like fields) * fix #42 (wrong field descriptions on validation errors) * redesign resource/field validation process
swistakm
changed the title
Support for *-sourced writable fields
Support for star-like writable fields
Apr 11, 2017
swistakm
added a commit
that referenced
this issue
Apr 11, 2017
* remove `source="*"` handling * move instance/representation manipulation responsibility to field objects to support nested objects and multiple key access pattern * update docs * fix #44 (writable star-like fields) * fix #43 (broken resource manipulation on star-like fields) * fix #42 (wrong field descriptions on validation errors) * redesign resource/field validation process
swistakm
added a commit
that referenced
this issue
Apr 19, 2017
* remove `source="*"` handling * move instance/representation manipulation responsibility to field objects to support nested objects and multiple key access pattern * update docs * fix #44 (writable star-like fields) * fix #43 (broken resource manipulation on star-like fields) * fix #42 (wrong field descriptions on validation errors) * redesign resource/field validation process
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We need to define how this should be handled. The easiest approach is to assume that fields with
source="*"
argument should return dictionary that will be added to theobject_dict
instance. Anyway this will make sense only with custom serializer fields. So maybe it would be better completely remove"*"
option from built-in parameters and maybe delegate set/get-attr/key responsibility to custom fields?The text was updated successfully, but these errors were encountered: