On Fri, Nov 6, 2009 at 11:41 AM, mattimust...@gmail.com
<mattimust...@gmail.com> wrote:
>
>> In my minds eye, I have a vision of a serialization framework that
>> would allow for registration of different serialization formats - not
>> just JSON/XML, but the fields and internal structure of a JSON
>> fixture, etc. Describing which fields should be rendered as lookups,
>> how the lookup would be determined, and under what conditions a lookup
>> should be used would all just be a configuration items on a
>> serialization definition.
>>
>> This is obviously a much larger body of work, and certainly wouldn't
>> get done for v1.2 - if only because I haven't done any planning,
>> prototype implementation, or community review.
>
> I have an obvious bias [1] but this would be my preferred option with
> Option 3 being implemented on top of it. I believe my Django Full
> Serializers implement 90% of what you are after (there is also a patch
> for reverse relations in the issue tracker). It is missing
> deserializing "full" serialized models and the ability to customize
> the internal structure of the output.

I've seen your Full Serializers before, and it looks like good stuff -
but I disagree about your '90% of the problem' analysis. To my mind,
including extra properties into the serialized data is the easy part
of the problem. The hard bit is getting real control over the
serialization format. Once you have good control over the
serialization format, serializing extra fields or deep relations is
almost a trivial afterthought.

I'm also hesitant to revisit the sins of modelform_factory and generic
views. Django has repeatedly discovered that trying to push
configuration through the argument list of a function is a recipe for
problems in the long term. To whit, from your own docs:

serializers.serialize('json', Group.objects.all(), indent=4,
relations={'permissions':{'relations':{'content_type':{'excludes':('app_label',)}}}})

The real solution is to use a full class-based representation.

> Would it be worth my while reworking my code as a patch against Django
> trunk?

At this point, probably not. A full serialization rewrite is on my
list of medium-term things to do (or list of things to try and
encourage other people to do :-), which is why the tickets around
'full serialization' have languished for so long. This is one of those
occasions where I'm deliberately not fixing part of the problem to
encourage attempts to fix the whole problem.

Yours,
Russ Magee %-)

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to