On Thu, Apr 2, 2009 at 2:24 PM, Russ <taal...@gmail.com> wrote:
>
> Thanks for the many, many pointers, Russ. Better ways of thinking
> about the problem have finally caught up to me. To illustrate my
> latest thoughts,
>
> class DefaultStructure(serializers.Structure):
> root_list = ("django-objects", {"version": "1.0"})
> object = ("object", {"pk": "%(pk)d", "model": "%(model_name)s"})
> field = ("field", {"type": "%(field_type)s", "name": "%(field_name)
> s"}, "")
> relations = ("field", {"to": "%(to)s", "name": "%(field_name)s",
> "rel": "%(relation_type)s"})
> # used by JSON and YAML, which don't use 'relations'
> relation_list = ("%(model_name_plural)s", {})
> related_object = ("object", {"pk": "%(pk)d"}, "")
>
> As is, this would, theoretically, produce the same serialized output
> as the current XML serializer.
>
> To explain, each attribute of AppStructure is (currently) a 2-tuple or
> 3-tuple containing the name of the node, the dictionary of attributes,
> and the value of the field, as appropriate. The string contents of
> each attribute is included as appropriate during the serialization
> process, with sensible interpolation arguments provided for
> convenience and clarity. Most of these are fields or field
> attributes, as appropriate, but some (e.g. "relation_type",
> "model_name_plural", "field_type") would be provided just for the
> convenience of it.
>
> It lacks the elegance you appreciated earlier, but that is essentially
> the building blocks of the current serializer's xml output. I want to
> think more on whether or not this could be condensed into something
> similar to my previous thought (the single 'structure' member), just
> to make the class a bit less verbose. I'll also explore some usage
> examples in the final application.
>
> Last-minute thoughts before the deadline?
There's still a lot of work required, but it sounds like you've
grasped them core of the idea I was pushing.
My advice to you at this point is that your proposal should pay more
attention to describing the problem that exists, rather than
describing your specific solution. While your API proposals are
getting better, I'm not convinced that what you have described here
will necessarily resemble the final solution. As such, making your
proposal about "implementing this API" will get you rejected pretty
quickly. However, if you pose it as "these are the problems that need
to be solved; here's the start of some ideas for fixing those
problems", your proposal will be more attractive.
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
-~----------~----~----~----~------~----~------~--~---
