Comments (22)
That's a good idea, do you see anything breaking from changing serializers? What about people who expected an exception and implemented their own serializers instead, will those break?
from django-annoying.
+1 on this... encoding Decimals is a must for me..
from django-annoying.
This is possible now. You can add into your settings:
FORMAT_TYPES = {
'application/json': lambda response: json.dumps(response, default=date_time_handler),
'text/json': lambda response: json.dumps(response, default=date_time_handler),
}
And use the serializer you want, including Django's. Can someone add a (tested) example in the docs so I can close this issue?
from django-annoying.
Slightly off-topic, but could you explain why the 0.7.9 version of django-annoying available through pypi (https://pypi.python.org/pypi/django-annoying/0.7.9) differs from the 0.7.9 version of code available here, on github? Don't they periodically refresh packages in the index?
As a result of that when you install django-annoying using pip you get an older version of the package that, among other things, lacks the support of settings-level customization of the FORMAT_TYPES dictionary.
from django-annoying.
That's very odd, you are right. It does differ. Maybe I forgot to bump the version? I will make a new release, thanks for the heads up.
from django-annoying.
I believe point of django-annoying is to eliminate certain annoyances in Django framework;) Need of specifying additional settings (that would be a hundredth something setting in a project) doesn't seem to be aligned with the goal above for me.
from django-annoying.
@cezio, sure, but do you have a better idea?
from django-annoying.
My concern here is that it will break things for current users. I do agree that the better serializer should be used by default...
from django-annoying.
How about the usual approach of creating a new decorator, and deprecating the old one?
(edited because mistyped, and sent too early)
from django-annoying.
Hmm, that's an idea, but the new decorator would necessarily be misnamed a bit, so I'm not a huge fan of this practice...
from django-annoying.
True. How about a configuration option that defaults to the old behavior:
@ajax_request(use_django_encoder=True)
def cost_view(request):
return {'total': Decimal("4")}
@ajax_request()
def user_view(request):
return {'id': 7}
Arguably, though, it's misnamed already β at least it confused me, since AJAX is just one particular way for a client to access the API. This decorator is really for API views, providing machine-readable representations of a resource, no? I.e. api_view
or api_response
might not be a bad fit. Or, more behavior-related names: encode_response
, encode_return_value
, β¦ well, just some thoughts. :)
from django-annoying.
The extra parameter still breaks backwards compatibility, since it's not called with parameters by default, but I really like the alternative names. Something like json_response
might be the most fitting, being very literal.
from django-annoying.
But it does support YAML, too, no? That's why I shed away from the JSON
name. :)
Also, Decorators that can be applied with and without arguments are possible, i.e. you don't have to break backwards-compatibility. You βmerelyβ need to consider the type of the first argument, if it's a function or not. If you always use keyword args for the arguments, then it would be perfectly safe, too. Might not be the most beautiful solution on your side of the code, but if you don't want to change the name, and still fix this issue, you can. :)
from django-annoying.
Yeah, you're right. I didn't consider that we'd never be accepting function arguments in normal usage, so I'll go with your proposed fix above. If anyone wants to beat me to a PR, you are very welcome to.
from django-annoying.
Just had to serialize something to JSON, and wanted to try out the built-in serializer. Turns out it is restricted to Django models. Also, a serialize-deserialize does not yield the same objects: For example, decimals stay a string.
So, I don't think this annotation should be switching to Django's serializer. At least I use API views for more than just plain Django models. If I'm missing something, do tell. :)
from django-annoying.
@mknecht, have you found something that the default json module will serialize but Django's JSON encoder won't? Decimals do stay a string, but the default JSON encoder produces an exception, so I'm not sure that's a valid comparison.
from django-annoying.
@skorokithakis It appears that the serializer will only serialize Django models. But, I would like to use the decorator for primitive object graphs, too, like a dict.
The linked documentation indicates that, and I tried and it refused to serialize dicts and such because they did not have a _meta
attribute.
from django-annoying.
That's odd, I've been using it for proper serialization of dates and it's worked fine. I'll investigate.
from django-annoying.
Maybe I misunderstood something. Thought it odd, too. I'd be glad to hear it works / what I did wrong. :)
from django-annoying.
No, you're right, works just fine. I must have messed something up. Sorry for the confusion. :)
from django-annoying.
Yo is it possible to have this issue closed up?
from django-annoying.
Certainly, PRs are welcome. I am a bit swamped right now :/
from django-annoying.
Related Issues (20)
- Django 3.2 compatibility? HOT 1
- Django5 Support? HOT 1
- Possible to add support for types? HOT 2
- Can we get Pypi updated with the thread safe changes? HOT 1
- Test don't run against Django 1.7+ HOT 2
- Django 1.9 HOT 6
- Django 1.9: Cannot import name SingleRelatedObjectDescriptor HOT 4
- JSONField is not working in Django 1.9+
- AutoOneToOne doesn't work HOT 14
- Remove pretty-print from the JSON field output or make it configurable HOT 2
- Django 1.11 middleware HOT 3
- Please add a release with a universal wheel to PyPI HOT 1
- Could you publish a new release? HOT 4
- AutoOneToOneField breaks Django admin lookups HOT 5
- Using AutoOneToOneField with proxy model HOT 2
- Race Condition Fix HOT 3
- Setting HTTP status code when using ajax_request HOT 3
- ImportError: cannot import name 'six' HOT 2
- I know this is ancient history but a breaking change in a point release? HOT 6
- Support for django v3 HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
π Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. πππ
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google β€οΈ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from django-annoying.