W dniu 07.05.2012 20:13, Tom Christie pisze:
Hey Piotr,
Here's a few comments...
You have 'fields' and 'exclude' option, but it feels like it's missing
an 'include' option - How would you represent serializing all the
fields on a model instance (without replicating them), and
additionally including one other field? I see that you could do that
by explicitly adding a Field declaration, but 'include' would seem
like an obvious addition to the other two options.
Default all model fields will be serialized and additional all fields
adding by Fields declaration. If 'fields' is set then only fields
present in 'fields' and additional fields added by Fields declaration
will be serialized. To many fields :). If exclude is set then all model
fields except fields set in exclude will be serialized and additional
fields added by explicit declaration. I think it's like in ModelForm
declaration. Did I'm missing some case?
I'd second Russell's comment about aliases. Defining a label on the
field would seem more tidy.
Likewise the comment about 'preserve_field_order' I've still got this
in for 'django-serializers' at the moment, but I think it's something
that should become private. (At an implementation level it's still
needed, in order to make sure you can exactly preserve the field
ordering for json and yaml dumpdata, which is unsorted (determined by
pythons dict key ordered).
I answer Russell about that
Being able to nest serializers inside other serializers makes sense,
but I don't understand why you need to be able to nest fields inside
fields. Shouldn't serializers be used to represent complex outputs
and fields be used to represent flat outputs?
At first I think Serializer should be tied with object (one Serializer =
one object). But then I figured out that Serializer can work with object
passed in upper level Serialized (so 'source' field isn't needed). Maybe
nested serializers and flat field is better approach. I must consider this.
The "class_name" option for deserialization is making too many
assumptions. The class that's being deserialized may not be present
in the data - for example if you're building an API, the class that's
being deserialized might depend on the URL that the data is being sent
too. eg "http://example.com/api/my-model/12";
I wrote about class_name in answer to Russell. If model class is in url
then we can do something like that:
serializers.deserialize("json", data_from_response,
deserializer=UserSerializer(class_name=model_from_url(url)))
In your dump data serializer, how do you distinguish that the 'fields'
field is the entire object being serialized rather than the 'fields'
attribute of the object being serialized?
fields = ModelFieldsSerializer(...) will be feed with object to
serialize and name 'fields'. I'm only interested at output from it. It
must be python native datatype and I do something like
serialized_dict['fields'] = output_of_mode_fields_serializer
ModelFieldsSerializer knows what do with object.
Also, the existing dumpdata serialization only serializes local fields
on the model - if you're using multi-table inheritance only the
child's fields will be serialized, so you'll need some way of handling
that.
Your PKFlatField implementation will need to be a bit more complex in
order to handle eg many to many relationships. Also, you'll want to
make sure you're accessing the pk's from the model without causing
another database lookup.
Thanks for point that. Have to think about it.
Is there a particular reason you've chosen to drop 'depth' from the
API? Wouldn't it sometimes be useful to specify the depth you want to
serialize to?
Sometimes maybe. But in most cases no. And there are some other ways to
do that. In my opinion going (globally) more than one level depth almost
never be needed. If there is need to go deeper in only one (or few but
not all) fields 'depth' is unusable.
There's two approaches you can take to declaring the 'xml' format for
dumpdata, given that it doesn't map nicely to the json and yaml
formats. One is to define a custom serializer (as you've done), the
other is to keep the serializer the same and define a custom renderer
(or encoder, or whatever you want to call the second stage). Of the
two, I think that the second is probably a simpler cleaner approach.
When you come to writing a dumpdata serializer, you'll find that
there's quite a few corner cases that you'll need to deal with in
order to maintain full byte-for-byte backwards compatibility,
including how natural keys are serialized, how many to many
relationships are encoded, how None is handled for different types,
down to making sure you preserve the correct field ordering across
each of json/yaml/xml. I *think* that getting the details of all of
those will end up being awkward to express using your current approach.
The second approach would be to a dict-like format, that can easily be
encoded into json or yaml, but that can also include metadata specific
to particular encodings such as xml (or perhaps, say, html). You'd
have a generic xml renderer, that handles encoding into fields and
attributes in a fairly obvious way, and a dumpdata-specific renderer,
that handles the odd edge cases that the dumpdata xml format requires.
The dumpdata-specific renderer would use the same intermediate data
that's used for json and yaml.
I can't agree with that. There are too big differences between existing
xml and json serializer output format. There is field 'fields' in json
and 'field' in xml. Xml has attributes and json not. It's only
presentation and these two cases could be handled in second phase (in
renderer). But there is one big difference - xml has additional fields
'to', 'rel', 'type' and these are not presentation. These are informations.
The next (and maybe most important) thing to consider is what user
should know about formats to be able to serialize his data. In your's
approach user should be familiar with for example SimpleXMLGenerator
because if he want
xml
<object>
<item>...</item>
<item>...</item>
</object>
and json
{
items : [ ..., ...],
}
then he must wrote at least one renderer to transform 'items' to 'item'
like you did in DumpDataXMLRenderer in django-serializers. I can't
accept that. Don't get me wrong, I adopt a lot of your's ideas from
django-serializers and I think is very good project. You shouldn't force
users to know anything about generating xml or any other format. Maybe
you should create some metalanguage for user to speak about what he want
like:
"I want that field 'items' will be transform to 'item' in xml (but I
don't know how to do it)" ->
class DumpDataSerializer(ModelSerializer):
"""
A serializer that is intended to produce dumpdata formatted structures.
"""
renderer_optons = {
'xml': { 'transform' : {'fields' : 'field'}} ,
}
It's ugly but I hope you understand my idea.
I hope all of that makes sense, let me know if I've not explained
myself very well anywhere.
Regards,
Tom
--
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.
