Re: Single-object serializers?
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 -~--~~~~--~~--~--~---
Single-object serializers?
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 -~--~~~~--~~--~--~---
Re: Customizing the settings configuration
One solution is to add an extra import at the bottom of your settings.py: try: from localsettings import * except ImportError: pass Then put localsettings.py in your svn:ignore, and override whatever settings you need to on a per-installation basis. On Jul 24, 2007, at 8:41 AM, gorans wrote: > I develop Django sites on my mac and then publish them to another web > server. In between, they live in a happy SVN repository on my > development server. > > Each time I make a change to the project's settings.py I have to then > go over and modify the live file version (in respect to the database > type / name, media directory etc.) > > I though that there could be a way to trick Django into reading > special development settings for me, something like having a settings > 'package' import separate settings files: > > e.g. > > myproject/ > > manage.py > ... > settings/ > __init__.py > coresettings.py > localsettings.py > > so that we use the variable from coresettings first, and then try: > import localsettings and if successful use those subsequent values. > > That way, I can have an un-versioned localsettings.py living on my > mac, whilst keeping the live settings intact. Additionally, other > developers on the project can do the same! > > Is this possible? (I'm sure it is but my Python just isn't good enough > to know how to import all the variables from each module) > > Can anyone please give me directions / pointers as to how to do this? > Or alternatively, how you deal with this task. > > Your help is very very much appreciated > > cheers > > Goran > > > > --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
