W dniu 31.08.2012 10:25, Tom Christie pisze:
> I personally think that Forms are already the place that should
handle (de)serialisation. They already serialise to HTML: why should
they not be able to serialise to other stream types?
Conceptually I agree. As it happens django-serializers is perfectly
capable of rendering into HTML forms, I just haven't yet gotten around
to writing a form renderer, since it was out-of-scope of the fixture
serialization functionality.
Pragmatically, I'm not convinced it'd work very well. The existing
Forms implementation is tightly coupled to form-data input and HTML
output, and I think trying to address that without breaking
backwards compatibility would be rather difficult. It's maybe easy
enough to do for flat representations, and pk relationships, but
extending it to deal with nested representations, being able to use a
Form as a field on another Form, and representing custom relationships
would all take some serious hacking. My personal opinion is that
whatever benefits you'd gain in DRYness, you'd lose in code
complexity. Having said that, if someone was able to hack together a
Forms-based fixture serialization/deserialization implementation that
passes the Django test suite, and didn't look too kludgy, I'd be
perfectly willing to revise my opinion.
I am not quite sure but I think Forms should be build based on some
serialization API not opposite. Forms are more precise way of models
serialization - they are models serialized to html (specific format)
with some validation (specific actions) when deserializing.
I like Tom's django-serialziers but there are some things that I want to
mention:
* Process of serialization is split to two parts - transformation to
python native datatype (serializer) and next to specific text format
(renderer). But when serializing also Field is saved with data so it's
not so clean. I also have an issues with this but I resolve it in
different way (not say better :)
* In master branch Serializer is closely tied to Renderer so if there is
different Renderer class than new Serializer is needed. In forms branch
it is done in __init__ serialize method and this must be rewrite for
backward compatibility if django-serializers goes to core. I want to
propose my solution [1]:
For each format there is Serializer class which is made from
NativeSerializer ( from models to python native datatype) and
FormatSerializer (Renderer)
class Serializer(object):
# class for native python serialization/deserialization
SerializerClass = NativeSerializer
# class for specific format serialization/deserialization
RendererClass = FormatSerializer
def serialize(self, queryset, **options):
def deserialize(self, stream_or_string, **options):
Deserializer = Serializer
This is fully backward compatible and user can do:
serializers.serialize('registered_format', objects,
serializer=MyNativeSerializer)
This will make new Serializer class with SerializerClass ==
MyNativeSerializer. In this solution NativeSerializer and
FormatSerializer are more independent. In my solution each
NativeSerializer can be render by each FormatSerializer but it's not so
simple. FormatSerializer provide NativeSerializer with some context so
you can tell that NativeSerializer knows what format will be serialized.
It's not exactly format but some metadata about it. I am not proud of
this :/
* IMO there is bug related to xml. All model fields must be transform to
text before xml serialization. In current django serialization framework
field's method value_to_string is responsible for this. In
django-serializers this method is not always called so it can lead to
error with custom model field
[1]
https://github.com/grapo/django/tree/soc2012-serialization/django/core/serializers
--
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.
