W dniu 26.06.2012 11:52, Tom Christie pisze:
> It is the way I am doing deserialization - pass instance to subfields
Seems fine. It's worth keeping in mind that there's two ways around
of doing this.
1. Create an empty instance first, then populate it with the field
values in turn.
2. Populate a dictionary with the field values first, and then create
an instance using those values.
The current deserialization does something closer to the second.
I don't know if there's any issues with doing things the other way
around, but you'll want to consider which makes more sense.
Second approach assume that every field returns some value. But what if
we don't want to deserialize some field? In my deserialization instance
is passed to field and field will eventually fill it with some value.
def deserialize_value(self, obj, instance, field_name):
setattr(instance, field_name, obj)
If we don't want to deserialize field we simply do nothing in
deserialize_value.
If second approach is used we must return value. Some idea is to mark
field as not deserializable:
class MyField(Field):
deserializable = False
> Where I returned (native, attributes) I will return (native,
metainfo). It's only matter of renaming but metainfo will be more than
attributes.
Again, there's two main ways around I can think of for populating
metadata such as xml attributes.
1. Return the metadata upfront to the renderer.
2. Include some way for the renderer to get whatever metadata it needs
at the point it's needed.
This is one point where what I'm doing in django-serializers differs
from your work, in that rather than return extra metadata upfront, the
serializers return a dictionary-like object (that e.g. can be directly
serialized to json or yaml), that also includes a way of returning the
fields for each key (so that e.g. the xml renderer can call
field.attributes() when it's rendering each field.)
Again, you might decide that (1) makes more sense, but it's worth
considering.
As ever, if there's any of this you'd like to talk over off-list, feel
free to drop me a mail - t...@tomchristie.com
Regards,
Tom
I rewrite this so it's more similar to django-serializers.
But from the beginning - what I do in this week? :)
I agreed that xml attributes in my solution are overstated. So I want
to modify it. Attributes in xml are one of (two) ways of presenting
information. I still want to have field for attributes, but doing it in
this way:
class MyField(Field):
attr1 = Field()
attr2 = Field()
def serialized_value(self, obj, field_name):
return field_value
def metainfo(self):
return {'attributes' : ['attr1', 'attr2']}
JSON will skip attributes at all:
some_field : field_value
XML will render it:
<some_field attr1=val1 attr2=val2>
field_value
</some_field>
If metainfo won't return dict with attributes XML will render this:
<some_field>
<attr1>val1</attr1>
<attr2>val2</attr2>
field_value
</some_field>
I code it like django-serializers's DictWithMeta but I added one more
functionality to represent Field that have subfields and one extra
value. I'm still not convicted it is good solution, so I rewrite it
several times but always end up with something like that :)
I will push code tomorrow because I still want to do some tweaks.
--
Piotr Grabowski
--
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.
