Hi Piotr; Apologies for the delay in responding to your updated API.
On Tue, May 22, 2012 at 6:59 AM, Piotr Grabowski <grabowski...@gmail.com> wrote: > I do some changes to my previous API: (https://gist.github.com/2597306 <- > change are included) > > * which fields of object are default serialized. It's depend on > include_default_field but opposite to Tom Christie solution it's default > value is True so all fields (eventually specified in Meta.model_fields) are > present Field options: ~~~~~~~~~~ * There's a complication here that doesn't make sense to me. Following your syntax, the following would appear to be legal: class FieldA(Field): def serialize(…): def deserialize(…): class FieldB(Field): to = FieldA() def serialize(…): def deserialize(…): class FieldC(Field): to = FieldB(attribute=True) def serialize(…): def deserialize(…): i.e., if Field allows declaration style definitions, and Field can be *used* in declaration style definitions, then it's possible to define them in a nested fashion -- at which point, it isn't clear to me what is going to be output. It seems to me that "attribute" shouldn't be an option on a field declaration; it should either be something that's encompassed in a similar way to serialise/deserialize (i.e., either additional input/output from the serialise methods, or a parallel pair of methods), or the use of a Field as a declarative definition implies that it is of type attribute, and prevents the use of field types that themselves have attributes. Field methods: ~~~~~~~~~~~ * serialize_value(), deserialize_value(); this is bike shedding, but is there any reason to not use just "serialize() and deserialize()"? ObjectSerializer methods: * Why does ObjectSerializer have options at all? How can it be "meta" operating on a generic object? Consider -- if you pass in an instance of an object, you'll need to use obj.field_name to access fields; if you pass in a dictionary, you'll need to use obj['field_name']. And if you're given a generic object what's the list of default fields to serialize? Like I said last time, ObjectSerializer should be completely definition based. Look at Django's Form base class - it has no "meta" concept -- it's fully declaration based. Then there's ModelForm, which has a meta class; but the output of the ModelForm could be completely manually generated using a base Form. * I mentioned this last time -- why is class_name a meta option, rather than a method on the base class with a default implementation? Having it as an Meta attribute * I'm not wild about the way related_serializer seems to work, either. Again, like class_name, it seems like it should be a method, not an option. By making it an option, you're assuming that it will have a single obvious value, which definitely won't be true -- e.g., I have an object with relations to users, groups and permissions; I want to output users as a list of nested objects, permissions as a list of natural keys, and groups as a list of primary keys. * I'm not sure I see why include_default_fields is needed. Isn't this implied by the values for "fields" and "exclude"? i.e., if fields or exclude is defined, you're not including everything by default; otherwise you are. Why the additional setting? What's the interaction of include_default_fields with fields and exclude? * I don't understand what follow_object is trying to do. Isn't the issue here whether you use a serializer that just outputs a primary key, or an object that outputs field values? And if it's the latter, the sub-serializer determines how deep things go? ModelSerializer options: * I'm really not a fan of model_fields. This seems like a short cut that will make the implementation a whole lot more complex, and ultimately is much less explicit than just naming the fields that you want to serialize. > I'm aware that there will be lot of small issues but I believe that ideas > are good. I'm still optimistic, but there's still some fundamental issues here -- in particular, the existence of Meta on ObjectSerializer, and the way that attributes on XML tags are being handled. I don't think we've hit any blockers, but we need to get these sorted out before you start producing too much code. 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.
