Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Renderer classes #1092

Closed
wants to merge 9 commits into from
Closed

Renderer classes #1092

wants to merge 9 commits into from

Conversation

mpuhacz
Copy link
Contributor

@mpuhacz mpuhacz commented Dec 15, 2017

Hello,

Recently I was working on API which handles a lot of float values in responses. One of the issues I encountered was having NaN values unquoted in the JSON response. simplejson allows changing those NaNs to null values in the fly using the ignore_nan=True argument. Eve has already this nice feature that allows using custom app.data.json_encoder_class but even if the custom JSON encoder class has ignore_nan set to True, that is still ignored and falls back to the default value which is False.

My idea is to have new key in the settings called RENDERERS. This is a tuple containing module path to Renderer classes. This way developer is allowed to simply extend the default Eve's functionality to new renderers. For example - using ujson, pyYaml.

This change is rather big, so I would love to get your feedback on this. If you feel like it's a good idea, I will continue working on it, updating docs and extending docstrings.

Best,
Marcin

@nicolaiarocci
Copy link
Member

Hello, this is an interesting work, I like where you are heading. One concern of mine is backward compatibility. People who have XML = False in their production settings will end up with XML enabled again after the upgrade.

Are you planning to address this? Or are you just counting on breakage warning in release notes instead?

@mpuhacz
Copy link
Contributor Author

mpuhacz commented Jan 4, 2018

Good point. Both ways have their pros and cons, but I would go for breakage warning (or even throwing DeprecationWarning) because of simplicity. On the other hand, we can support both of JSON and XML and then create RENDERERS on the fly, but that would mean more complexity(an e.g. new method that checks for usage of deprecated features). I would love to keep it as simple as possible. What is your preferred approach?

@nicolaiarocci
Copy link
Member

I was going to suggest we issued deprecation warnings, but I see you went ahead and added the implementation already, excellent.

@nicolaiarocci nicolaiarocci added this to the 0.8 milestone Jan 8, 2018
@nicolaiarocci
Copy link
Member

Please, go ahead with documentation updates.

@mpuhacz
Copy link
Contributor Author

mpuhacz commented Jan 16, 2018

@nicolaiarocci The docs are updated - hopefully I didn't miss anything. 😃

nicolaiarocci added a commit that referenced this pull request Jan 18, 2018
@nicolaiarocci
Copy link
Member

nicolaiarocci commented Jan 18, 2018

Rebased and merged: 80ded9d

Thank you!

nicolaiarocci added a commit that referenced this pull request Jan 18, 2018
lexhung added a commit to lexhung/eve that referenced this pull request Dec 12, 2018
* upstream/master: (28 commits)
  Changelog for pyeve#1114 and pyeve#1115.
  docs: Use correct name for form-data mime type
  Olof Johansson
  docs: Refer to example resources (contacts) consistently
  kreynen
  Fixed typo
  Bump Flask requirement to <=0.13
  Fix broken links in documentation/configuration page.
  Bump version to 0.7.8
  Fix breaking syntax error in v0.7.7
  Bump version to 0.7.7
  Add $geometry and $maxDistance to mongo operators
  Changelog for pyeve#1092
  Updated authors
  Updated docs
  Updated docstrings
  Checking for deprecated features proposal - typo fix
  Checking for deprecated features proposal
  PEP8 compliance
  Updated py2.6 dependencies
  ...
# for free to join this conversation on GitHub. Already have an account? # to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants