On Sat, May 5, 2012 at 4:08 AM, Piotr Grabowski <grabowski...@gmail.com> wrote:
> Hi,
>
> During this week I have a lot of work so I didn't manage to present my
> revised proposal in Monday like i said. Sorry. I have it now:
> https://gist.github.com/2597306
Hi Piotr,
At a high level, I think you're headed in the right direction. I like
the way you've separated Field and Serializer, and I like the way that
Serializer represents on "nesting level" of the final output (so if
you want complex formats for a single object, such as with the way
Django's JSON serializer has id, model and fields at the top level,
you nest Serializers to suit).
Here's some specific feedback:
* I can see that ModelSerializer will play an important part in your
proposal. However, some of your API proposals seem a little
unnecessary -- or are unclear why they're needed. Some areas that need
clarification:
- I'm not sure I follow how class_name would be used in practice. The
act of deserialization is to take a block of data, and process it to
populate an object.
In the simplest case, you could provide an empty instance (or factory)
that is then populated by deserialization. In this case, no class name
is required -- it's provided explicitly by the object you provide.
A more complex case is to use the data itself to determine the type of
object to create. This seems to be the reason you have "class_name",
but I'm not sure it's that simple. Consider a case where you're
deserializing a thing of objects; if the data has a "name" attribute,
create a "Person" object, otherwise create a "Thing" object. The
object required is well defined, but not neatly available in a field.
There's also no requirement that deserialization into an object is
handled by a ModelSerializer. ModelSerializer should just be a
convenient factory for populating a Serializer based on attributes of
a model -- so anything you do with ModelSerializer should be possible
to do manually with a Serializer. If class_name is tied to
ModelSerializer, we lose this ability.
- I'm not sure I see the purpose of "aliases" -- or, why this role
can't be played by other parts of the system. In particular, I see
Field() as a definition for how to fill out one 'piece' of a
serialised object. Why doesn't Field() contain the logic for how to
extract it's value from the underlying object?
- Why is preserve_field_ordering needed? Can't ordering be handled by
the explicit order of field definitions, or the ordering in the
"fields" attribute?
* As a matter of style, serializer_field_value and
deserialize_field_value seem excessively long as names. Is there
something wrong with serialize and deserialize?
* I don't think getattr() works quite how you think it does. In
particular, I don't think:
getattr(instance, instance_field_name) = getattr(obj, field_name)
will do what you think it does. I think you're looking for setattr() here.
* Can you elaborate some more on the XML attribute syntax in your
proposal? One of your original statements (that I agree with) is that
the "format" is independent of the syntax, and that a single set of
formatting rules should be able to be used for XML or for JSON. The
big difference between XML and JSON is that XML allows for values to
be packed as attributes. I can see that you've got an 'attribute'
argument on a Field, but it isn't clear to me how JSON would interpret
this, or how XML would interpret:
- A Field that had multiple sub-Fields, all of which were attribute=True
- A Field that had multiple sub-Fields, several of which were attribute=False
- The difference between these two definitions by your formatting rules:
<key attr1="val1" attr2="val2">
<subkey>subval</subkey>
</key>
<key attr1="val1" attr2="val2">main value</key>
In particular, why is the top level structure of the JSON serializer
handled with nested Serializers, but the structure of the XML
serializer is handled with nested Fields?
> Next week I hope there will be some discussion about my proposal. I will
> also think how it should be done under the hood. There should be some
> internal API. I should also resolve one Django ticket. I think about this
> https://code.djangoproject.com/ticket/9279 There will be good for test cases
> in my future solution.
I would suggest that you don't spend *too* much time on this. It's
certainly a good idea to get to know our committing procedures, and
historically we've encouraged students to get to use working on a
small ticket as a way to do this. However, your project is unusual in
that you've been accepted without a firm API proposal. Given that you
won't really be able to work on the GSoC without an accepted proposal,
I'd suggest that your API should take precedence in your pre-GSoC
plans.
> I should write my proposal on this group? In github I have nice formatting
> and in this group my Python code was badly formatted.
It's up to you; however, the problem with posting to a Gist (or
similar) is that it's very hard to comment on specific parts of your
proposal. I know code formatting is a pain in Google groups, but it is
a much better discussion forum.
Yours,
Russ Magee %-)
--
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.
