Thanks Piotr,
> But when serializing also Field is saved with data so it's not so clean.
I'm not sure whether it's an issue or not. As with Django's form fields,
the fields are copied off of base_fields, so saving state
isn't necessarily a problem. I'd agree that it's possibly not the cleanest
part of the API, but it might be good enough.
> For each format there is Serializer class which is made
from NativeSerializer ... and FormatSerializer
That would work.
I was planning on taking a slightly different approach in order to merge
the work into Django.
In my opinion the `SERIALIZATION_MODULES` setting wouldn't make much sense
once serialization and parsing/rendering are decoupled. Furthermore it
places some very specific, slightly odd, and
undocumented constraints on the interface that serialization modules must
provide. Eg. They must include a class named 'Serializer' and a class
named 'Deserializer'.
My preference would be to put that setting on the road to deprecation,
replacing it with something more appropriate, eg:
SERIALIZER_CLASS='django.core.serializers.FixtureSerializer'
RENDERER_CLASSES=(...)
PARSER_CLASSES=(...)
It'd be possible to do that in a way that'd be consistent with Django's
deprecation policy, if the initial release continued to check
if SERIALIZATION_MODULES is set, and use that in preference to the new
style settings.
The `serialize`, `deserialize` and `get_serializer` functions continue to
exist and would be light backward-compatible wrappers around the core of
the new-style serialization.
Having said that I could probably live with either approach.
I guess it would probably make sense for me to pull django-serializers into
a fork of django at some point, to better demonstrate what I'm suggesting.
> * 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.
Thanks. I've not looked into that yet. It sounds feasible, though I
think it'd have to only be affecting custom model fields in xml, and should
be easy enough to fix. If it's easy for you to provide an example case
where django-serializer's output differs from the existing fixtures it'd be
much appreciated.
Regards,
Tom
On Saturday, 1 September 2012 12:39:32 UTC+1, Piotr Grabowski wrote:
>
> 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 view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/sUfdW7VqDKQJ.
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.
