> if I put list in input I want list in output, not generator

I wouldn't worry about that.  The input and output should be *comparable*, 
but it doesn't mean they should be *identical*.
A couple of cases for example:

*) You should be able to pass both lists and generator expressions to a 
given serializer, but they'll end up with the same representation - there's 
no way to distinguish between the two cases and deserialize accordingly. 
*) Assuming you're going to maintain backwards compatibility, model 
instances will be deserialized into 
django.core.serializer.DeserializedObject instances, rather than 
deserializing directly back into complete model instances.  These match up 
with the original serialized instances, but they are not identical objects. 

> 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?  I'd suggest that the deserialization hook for a field needs to take 
eg. the dictionary that the value should be deserialized into, then it can 
determine which key to deserialize the field into, or simply 'pass' if it 
doesn't deserialize a value.

> 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


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.

Reply via email to