When I started rewriting the API for addons.mozilla.org, my views were mostly the same: get some data and render it as either JSON or XML. I also wanted all my API methods to take an api_version parameter, so I decided class based views would be best. This way my classes could just inherit from a base class.
To do this I had to implement a __call__ method. This works fine, except I wanted to store things into the class -- after all the whole point of my use of classes was to keep the code a bit more compact, and cleaner. So, why pass the api_version around everywhere? Unfortunately thread-safety comes to play, and you need a separate instance of your class for each request.
Continue reading 'λ^2: safely doing class based views in Django'
Filed under spindrop. |
Tags: django && lambda && mozilla && python && views
I just released Fixture Magic.
When dealing with legacy data, you'll run into all kinds of edge cases. Perhaps, an object might not display correctly unless it has the right parameters, or if it has null parameters it might not display at all. So when testing Django, it's nice to actually use non-dummy data.
Luckily Django has a way of pulling real data out of your database using django.core.serializers:
from addons.models import Addon
a = Addon.objects.get(id=3615)
from django.core.serializers import serialize
jsonize = lambda a: serialize("json", a, indent=4)
jsonize([a])
This solution runs well in a Django shell and can be lots of fun for the whole family... until things get complicated.
Continue reading 'django-fixture-magic: Testing issues with real data.'
Filed under spindrop. |
Tags: addons.mozilla.org && django && fixtures && mozilla && testing
