On Thu, Apr 2, 2009 at 2:24 PM, Russ wrote:
>
> Thanks for the many, many pointers, Russ. Better ways of thinking
> about the problem have finally caught up to me. To illustrate my
> latest thoughts,
>
> class DefaultStructure(serializers.Structure):
> root_list = ("django-objects", {"versio
Thanks for the many, many pointers, Russ. Better ways of thinking
about the problem have finally caught up to me. To illustrate my
latest thoughts,
class DefaultStructure(serializers.Structure):
root_list = ("django-objects", {"version": "1.0"})
object = ("object", {"pk": "%(pk)d", "mod
On Wed, Apr 1, 2009 at 2:10 PM, Russ wrote:
>
> Questions for the time-pressed:
>
> * Have you ever needed, or can you conceive of ever wanting, to
> provide multiple formats (JSON/XML/etc) for the same data? In other
> words, is there a use case for easily producing different
> serializations of
Questions for the time-pressed:
* Have you ever needed, or can you conceive of ever wanting, to
provide multiple formats (JSON/XML/etc) for the same data? In other
words, is there a use case for easily producing different
serializations of the same data?
* If you could serialize data in whatever
On Tue, Mar 31, 2009 at 11:43 AM, Russ Amos wrote:
> I appreciate you taking the time to identify my now-glaring misconceptions,
> Russ (... I have to laugh. I've never met another Russ).
Soon we will take over the world. :-)
> Would writing an appropriate template, while certainly not ideal,
I appreciate you taking the time to identify my now-glaring misconceptions,
Russ (... I have to laugh. I've never met another Russ). I would like to
finish airing out my naivete before attempting to salvage my proposal before
the due date.
Would writing an appropriate template, while certainly no
On Mon, Mar 30, 2009 at 5:57 AM, Russ wrote:
>
> My apologies for the length!
>
>
> Concisely, I intend to provide the Django user with some granular
> control of the data to be serialized without sacrificing backwards
> compatibility for old code, or for users who need the straightforward,
> cur
Okay, so I've uploaded the code for the serializer so you can take a
look: https://gist.github.com/9167eff88d787b3b5279
Disclaimer: Again, I freely admit that this code is extremely messy
and may well contain a few bugs (I don't have any test cases for it).
It isn't something I use on a productio
Oliver, examining unique and unique_together attributes is exactly what I
have in mind for attempting to follow relationships when deserializing. I
realize it needs to be dealt with carefully in the inner workings of Django,
to provide consistency, but anything you're willing to provide, I'm willin
I'll admit that I haven't read your whole post (sorry), but one part
caught my eye… the bit about storing relationships not just as primary
keys. If I am right in thinking that you are wanting to do some sort
of "relationship following" I think I can probably help by providing
some initial (but a
My apologies for the length!
Concisely, I intend to provide the Django user with some granular
control of the data to be serialized without sacrificing backwards
compatibility for old code, or for users who need the straightforward,
current functionality.
Any serialized Model contains only the
11 matches
Mail list logo
