On Wed, Jul 11, 2012 at 8:18 AM, Piotr Grabowski <grabowski...@gmail.com> wrote: > Hi, > > It is time to midterm evaluation of my participation in gsoc so I want to > summarize in this check-in what I have done in last month. > https://gist.github.com/3085250 - here is something that can be > "documentation". I wrote some examples of ModelSerializer usage and how it > should work. > https://github.com/grapo/django - in branch soc2012-serialization is code > that I wrote.
It's good that you're starting to work on some documentation -- my feedback is that you need to think about the purpose of this documentation -- I can discover the API myself with Python's interactive shell; what that won't tell me is what output I will expect. For example, you give an example of how to defined a 'metadata' method, but you don't show the effect of adding that declaration on the output serialised object. In fact, there doesn't seem to be a single example of serialised *output* in the whole docs. Giving lots of code examples of input doesn't really help me unless I know how that input will shape the output. This is especially important when we're dealing with serializers. > There is still problem with API and how to do some things but in my opinion > it's going in right direction. Generally, I agree. I still have some concerns however; mostly around the things that you're putting onto the Meta class. related_serializer, for example -- Why is this a single attribute in the meta, rather than a method? By using an attribute, you're saying that on any given serializer, *all* related objects will be serialised the same, and I don't see why that should be the case. The same argument goes for class_name (which I think I've mentioned before), field_serializer, and so on. The only fields that I can see that *should* be declarative are 'fields' and 'exclude' -- and if you've been tracking django-dev recently, there's been a discussion about whether the idea of 'exclude' should be deprecated from Django APIs (due to potential security issues -- explicit inclusion is safer than implicit inclusion, because you can accidentally forget to exclude sensitive data from an output list) Some other API questions: Why is deserialized_value decoupled from set_object? It isn't obvious to me why this separation exists. I see where you're going with metainfo on fields (and that's a reasonably elegant way of tackling the problem of XML needing additional info to serialize), but what is the purpose of metadata on Serializers? > Serialization and deserialization of Python objects is almost done. There is > quite stable API, i used some ideas (and little code) from > https://github.com/tomchristie/django-serializers > Objects are serialized to metadicts which are dicts with additional data. > this additional data can be used by format serializer to change presentation > of data (e.g. attributes in xml) > > Serialization of Django models is started. I don't know what fields of model > should be serialized by default: for sure all declared in model fields. What > with pk field, reverse related fields? Your goal here should be to exactly replicate Django's existing serializers. That means serialising all local model fields, with the PK being handled as a special case; reverse related fields aren't included. > Json dumpdata serializer is more or less written - I have not done fields > sorting yet. > > I am sure that I can finish all this work until gsoc end. > > Sadly not all is going well. Especially my communication in this list and > with my mentor should be improved. It's all by my fault. I should wrote > check-ins more regularly and meet the deadlines that I set. I am not very > satisfied with progress I have made. It can be done much more in about one > and a half month. My sincere apologies for not responding as often as I should. I haven't been a very good mentor for this project. I'll try and improve for the second half of the GSoC. I can see you've been getting some feedback from Tom Christie; the good news is that I'm generally in agreement with the feedback he's been giving you, so he hasn't been leading you astray :-) If you ever want to get my attention for a solid block of time to kick around an idea, you can alway grab me on IRC. I lurk in #django-dev most of the time. 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.
