On Wed, Apr 6, 2011 at 11:31 AM, DaNmarner <danmar...@gmail.com> wrote: >> So - show me what it would look like. Show me how I, as a third party, >> would use your proposed syntax to define output that would match >> Django's existing serialization scheme. Yes, this serialization format >> will exist as a built in default; but I should be able to reproduce >> that format in my own code if I want. > > # Fair enough. > > if code > literacy: # here > so_be_it() > > > class DefaultSerializedField(object): > belongs_to = "field" > as_tag = true > > class DefaultSerializedSpecialField(DefaultSerializedField): > " For pk and modelname " > belongs_to = None > as_tag = false > > class DefaultSerializedModel(object): > exclude = [] > fields = None > def __init__(self,embed_level): > self.embed_level = embed_level > > > #Somewhere in the dark forest of BaseSerializer implemented > > if not config_is_passed_as_an_arg: > config = DefaultSerializedModel(embed_level=0) > > for item in queryset: > pk_config = getattr(config, 'pk', DefaultSerializedSpecialField()) > self.process_pk(pk_config) > > mn_config = getattr(config, 'modelname', > DefaultSerializedSpecialField()) > self.process_model_name(mn_config) > > fields = getattr(config, 'fields',()) > for name, field_config in fields.: > if not name_of(field) in item.exclude: > self.process_field(name, field_config) > if not fields: > default_config = DefaultSerializedField() > for field in regular_field_of(item): > if not name_of(field) in item.exclude: > self.process_field(name_of(field), default_config) > > The idea is not to abandon all current assumption about how > serialization proceeds, but to do so only to a degree such that we get > the flexibility needed.
No. The idea is to *explicitly encode* the current assumptions, which implicitly allows someone else to define a different set of assumptions. The purpose of this project is to define (and then implement) a DSL for serialization. Django's existing serialization format is just one output product that can be defined using that DSL; ideally, the DSL would be sufficiently expressive to allow any output format to be defined. I would also note that you haven't taken the bait I have repeatedly offered (once in a reply to you, once in the other currently active thread, and many times in the past). Django's serialization language is just one example of an output format. Showing that you can handle a pathological case is a much more rigorous test. 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.
