Sorry... after reading that back to myself, I realize that the first sentence might be a little confusing:
Just to clarify: I'm *building* an API that will output XML and JSON using Django serializers. I realize that the Django serialization API is subject to change. On Aug 8, 2007, at 12:41 PM, Shawn Allen wrote: > Hey everyone, > > I'm about to tackle an API that supports multiple response formats > using serializers. I realize that the API (as simple as it is) is > subject to change, but it seems like a totally sensible pattern for > what I'd like to do. One problem I've come across already is that the > base Serializer class's serialize() method assumes whatever is passed > to it is an iterable. This is a poor assumption in the case of my > API, which, in many cases, will be returning a serialized > representation of a single object. Can anyone recommend a strategy > for overriding this behavior? A couple of options I'm considering: > > - create iterable classes that represent "single object collections", > and generic classes to handle them > - register serialization format classes that do single object > serializations > > The latter could be particularly hairy because it requires copying a > lot of code from django.core.serializers.base.Serializer. The way > that serialize() is written now, at least, it's cleaner to create > classes that override start_serialization(), end_serialization(), and > all of the other methods called in between. > > Has anyone else come up with an elegant solution for this yet? > > Thanks, > Shawn > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
