On 17/03/11 07:47, Vivek Narayanan wrote: > Hi, > > This is my proposal for the customizable serialization idea:
Hi Vivek - sorry about the long reply-wait on this! My initial thoughts are below. > The user can define methods beginning with “meta_” to add metadata > about each field. And functions starting with “meta2_” can be used to > add metadata at the model level. Here is an example: > > ... > > The existing implementation of ``model.name`` and ``model.pk`` can be > described using “meta2_” functions. These will be provided as > ``meta2_name`` and ``meta2_pk`` to facilitate loading and dumping of > fixtures. I'm unclear about what meta2_ accomplishes - is it for things that are not fields, but still serialisable? Surely there's a better way to go about this? > Permission Framework > ================= > While creating an API, there may arise a need to give varying levels > of access to data to different people. For this I propose a permission > framework, where the user can choose to restrict data to certain > groups while defining a model. I'm not entirely sure this is something that should be in the same scope as the main project - adding user permissions into a serialisation framework feels a bit ugly, especially when it's relatively easy for people to implement themselves (with the exclude arguments, etc) > • An extras argument, which would allow properties and data returned > by some methods to be serialized. How, exactly? What do you pass in this argument? > ----------------------------------------------------------------- > Representing the existing serialization model > ----------------------------------------------------------------- > Here is an implementation of the existing serialization format in > JSON, this would be the ‘fixture’ mode that I’ve mentioned above. Presumably you're planning to leave the existing fixture-loading code as it currently is, given that there's no mention of it here? Are the customisable serialisers purely for use by other, non-Django applications in your plan? > =================== > Deliverables and Timeline > =================== > > I would be working for about 40-45 hours each week and I would be > writing tests, exceptions and error messages along with development. > This would more or less be my timeline: > Are you really going to be able to commit 40-45 hours a week? That's a significant commitment, and more than many full-time jobs (in addition, I don't see this being 400 man-hours' worth of work - not that that's a bad thing, we'd rather it was less, as that's a lot of work to commit to) I also haven't seen any proposals or examples of how I'd use the API as an end user - are people going to be able to register serialisers to models (since they're apparently tied to specific models anyway)? How about if I just want to customise how the serialiser outputs DateTimeFields, or tell it how to serialise my new, shiny, custom field - does your proposal have any way to override things on a field type basis? Those are my initial reactions on the first reading of the proposal with your change to authentication added in - don't take any criticism too harshly, we just have to be thorough. Andrew -- 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.
