> default deserialized_value don't returns anything. It sets the field
value.
Cool, that's exactly what I meant.
> but declaring function only to say "do nothing" isn't good solution for
me.
<shrug> Declaring a method to simply 'pass' seems fine to me if you want to
override it to do nothing.
> 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.
> 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
On Wednesday, 20 June 2012 16:28:51 UTC+1, Piotr Grabowski wrote:
>
> 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 view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/MseHqWa-jb8J.
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.
