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

Renderer classes #1092

Closed
wants to merge 9 commits into
base: master
from

Conversation

Projects
None yet
3 participants
@mpuhacz
Contributor

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

This comment has been minimized.

Member

nicolaiarocci commented Dec 26, 2017

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

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

nicolaiarocci commented Jan 8, 2018

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

This comment has been minimized.

Member

nicolaiarocci commented Jan 8, 2018

Please, go ahead with documentation updates.

@mpuhacz

This comment has been minimized.

Contributor

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

This comment has been minimized.

Member

nicolaiarocci commented Jan 18, 2018

Rebased and merged: 80ded9d

Thank you!

nicolaiarocci added a commit that referenced this pull request Jan 18, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment