W dniu 20.06.2012 13:50, Tom Christie pisze:
>deserialized_value function with empty content
Are you asking about how to be able to differentiate between a field
that deserializes to `None`, and a field that doesn't deserialize a
value at all?
No :) I had this problem before and I managed to resolve it - default
deserialized_value don't returns anything. It sets the field value.
def deserialized_value(self, obj, instance, field_name):
setattr(instance, field_name, obj)
It is the way I am doing deserialization - pass instance to subfields,
retrieve it from them (should be same instance, but in specific cases
eg. immutable instance, I can imagine that another instance of same
class is returned) and return it.
If I don't declare deserialized_value function then function from base
class is taken. It's expected behavior. So how to say "This field
shouldn't be deserialized". Now I declare:
def deserialized_value(self, obj, instance, field_name):
pass
For true, I can do anything in this function excepting set some value to
instance, but declaring function only to say "do nothing" isn't good
solution for me.
> I changed python datatype format returned from serializer.serialize
method. Now it is tuple (native, attributes)
I'm not very keen on either this, or on the way that attributes are
represented as fields.
To me this looks like taking the particular requirements of
serializing to xml, and baking them deep into the API, rather than
treating them as a special case, and dealing with them in a more
decoupled and extensible way.
For example, I'd rather see an optional method `attributes` on the
`Field` class that returns a dictionary of attributes. You'd then
make sure that when you serialize into the native python datatypes
prior to rendering, you also have some way of passing through the
original Field instances to the renderer in order to provide any
additional metadata that might be required in rendering the basic
structure.
Wiring up things this way around lets you support other formats that
have extra information attached to the basic structure of the data.
As an example use-case - In addition to json, yaml and xml, a
developer might also want to be able to serialize to say, a tabular
HTML output. In order to do this they might need to be able attach
template_name or widget information to a field, that'd only be used if
rendering to HTML.
It might be that it's a bit late in the day for API changes like that,
but hopefully it at least makes clear why I think that treating XML
attributes as anything other than a special case isn't quite the right
thing to do. - Just my personal opinion of course :)
Regards,
Tom
You right that I shouldn't treated attributes so special. I have idea
how to fix this. Where I returned (native, attributes) I will return
(native, metainfo). It's only matter of renaming but metainfo will be
more than attributes. In xml metainfo can contains attributes for field,
in html it can be template_name or widget for rendering. If I don't use
metainfo in my serializer class then it's still universal - can be used
for serialization to any format.
How to create metainfo? Have a method `metainfo' in `Field` class that
returns a dictionary seems to be good idea. And it is for this use-cases
for html. But what to do with xml attributes again? :) They aren't only
field meta informations but they can also contains instance information
valuable in deserialization (like instance pk in current django
solution) so they should be treated as fields, should have access to
instance in serialization and deserialization.
My last thought is that attributes should be treated as normal fields
and be in tuple's native object and in metainfo there will be
information for xml which fields in native should be rendered as attributes.
After first phase:
native =={
'field_1' : value1,
'field_2' : value2,
'field_3' : value3,
}
metainfo == {
'as_attributes' : ['field_2', 'field_3'],
'template_name' : 'my_template'
}
So if we use json in second phase field_2 and field_3 will be render
same way as field_1 because json don't read metainfo. Xml will render
fields according to metainfo['as_attributes']. Html will render native
dict using my_template.
--
Piotr Grabowski
On Tuesday, 19 June 2012 21:48:37 UTC+1, Piotr Grabowski wrote:
Hi!
This week I wrote simple serialization and deserialization for
json format so it's possible now to encode objects from and to json:
import django.core.serializers as s
class Foo(object):
��� def __init__(self):
������� self.bar = [Bar(), Bar(), Bar()]
������� self.x = "X"
class Bar(object):
��� def __init__(self):
������� self.six = 6
class MyField2(s.Field):
��� def deserialized_value(self, obj, instance,� field_name):
������� pass
class MyField(s.Field):
��� x = MyField2(label="my_attribute", attribute=True)
��� def serialized_value(self, obj, field_name):
������� return getattr(obj, field_name, "No field
like this")
��� def deserialized_value(self, obj, instance,� field_name):
������� pass
class BarSerializer(s.ObjectSerializer):
��� class Meta:
������� class_name = Bar
class FooSerializer(s.ObjectSerializer):
��� my_field=MyField(label="MYFIELD")
��� bar = BarSerializer()
��� class Meta:
������� class_name = Foo
foos = [Foo(), Foo(), Foo()]
ser = s.serialize('json', foos, serializer=FooSerializer, indent=4)
new_foos = s.deserialize('json', ser, deserializer=FooSerializer)
There are cases that I don't like:
* deserialized_value function with empty content - what to do
with fields that we don't want to deserialize. Should be
better way to handle this,
* I put list foos but return generator new_foos, also bar in Foo
object is generator, not list like in input. Generators are
better for performance but if I put list in input I want list
in output, not generator. I don't know what to do with this.
Next week I will handle rest of issues that I mentioned in my last
week check-in and refactor json format (de)serialization - usage
of streams and proper parameters handling (like indent, etc.)
--
Piotr Grabowski
--
You received this message because you are subscribed to the Google
Groups "Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/XwdU_QQYDmAJ.
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.
--
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.
