Hi Russell,
After some thinking again, I have re-worked on my proposal and come up
with the following idea. Here is my draft proposal. I have also submitted it
to socghop.appspot.com
Let us consider the following two models for discussion through out:
class Poll(models.Model):
question = models.CharField(max_length=200)
pub_date = models.DateTimeField('date published')
creator = models.CharField(max_length=200)
valid_for = models.IntegerField(max_length=200)
def __unicode__(self):
return self.question
class Choice(models.Model):
poll = models.ForeignKey(Poll)
choice = models.CharField(max_length=200)
votes = models.IntegerField()
def __unicode__(self):
return self.choice
This projects begins by providing ModelAdmin and Feeds framework
like APIs for Serializers where the user now will be able to construct
a class for specifying custom serialization formats. I propose the API
based on the following ideas.
The user will first define a Class inherited from the Serializer
framework. The parent class is a generic base Serializer class. The
user defined class is then passed as a parameter to the serialize
method we call when we want to serialize the Models. Within this class
the user will be able to specify the customized serialization format
in which he desires the output. Since Python supports majorly three
data structures, Lists, Tuples and Dictionaries, this format can
contain any of these data structures in any possible order. Examples:
Example 1:
class PollSerializer(Serializer):
custom_format = [("question", "valid_for", "id")]
The output in this case will be a list of tuples containing the values
of question, valid_for and id fields. Here the strings are the names
of the fields in the model.
OR
Example 2:
class PollSerializer2(Serializer):
custom_format = (["question", {
"valid_for_number_of_days": "valid_for"
"Poll ID": "id"
}])
The output in this case will be a tuple of lists containing the values
of question and a dictionary which contains valid_for and id fields
as values and their description as keys of a dictionary.
The implementation although not trivial, will work as follows:
(This is not final. Final implementation will be worked out by
discussing with the community)
- The custom_format will be checked for the type. The top level
structure will be decided from this type. "{}" if dictionary, "()"
if tuple and "[]" if list. In case of XML, the root tag will be
django-objects. Also its children will have tag name as "object"
and include model="Model Name" in the tag. This is same as the
existing XML Serializer till here.
- Further the type of the only item within the top-level structure
is determined. All the django objects serialized will be of this
type. In case of XML, the children of "object" tag will be the tags
having the name "field". The tags will also have name="fieldname"
and type="FieldType" attributes within this tag. Additionally if
these field tags are items of the dictionary, they will have a
description="dictionary_key" attribute in the field tag.
- Further each item within the inner object("question","valid_for"
and "id" in the first example) is checked for the type and the
serialized output will have corresponding type. This is implemented
recursively from this level. In case of XML, however, the name of
the tag for further level groupings will have to be chosen in some
consistent way. My suggestion for now is to name the tags as
"field1" for the third level in the original custom format structure,
"field2" for the fourth level in the original custom format
structure, and so on.
For the second example above, we call the serializer as follows:
serializer.serialize("json", Poll.objects.all(),
custom_serializer=PollSerializer2)
The output looks as follows:
(
["What's Up?", {
"valid_for_number_of_days": "30"
"Poll ID": "1"
}
],
["Elections 2009", {
"valid_for_number_of_days": "60"
"Poll ID": "2"
}
]
)
Also if we use XML,
serializer.serialize("xml", Poll.objects.all(),
custom_serializer=PollSerializer2)
The output looks as follows:
<django-objects version="1.0">
<object pk="1" model="testapp.poll2">
<field type="CharField" name="question">What's Up?</field>
<field>
<field1 type="IntegerField" name="valid_for"
description="valid_for_number_of_days">
30
</field1>
<field1 type="AutoField" name="id" description="POLL ID">
1
</field1>
</field>
</object>
<object pk="2" model="testapp.poll2">
<field type="CharField" name="question">Elections 2009</field>
<field>
<field1 type="IntegerField" name="valid_for"
description="valid_for_number_of_days">
60
</field1>
<field1 type="AutoField" name="id" description="POLL ID">
2
</field1>
</field>
</object>
</django-objects>
Further when a user wants to include extra fields in the serialized
data like additional non-model fields or computed fields, he needs
to specify the name of the method in the class that returns the value
of this field as the value of that item in his format. It should not
be a String. So that we can check if the item value is callable
and if so we can call that method and use the return value for
serialization. For example:
Example 3:
class PollSerializer(Serializer):
custom_format = [("question", "valid_for", till_date)]
def till_date(self):
import datetime
delta_time = datetime.timedelta(
days=Poll.objects.get(pk=self.pk).valid_for)
new_datetime = Poll.objects.get(pk=self.pk).pub_date +
delta_time
return new_datetime
Further an important thing to note here is that, whenever the string
passed as an item value to the custom_format anywhere in the whole
format doesn't evaluate to any field in the model, it is serialized as
the same string in the final output, thereby allowing addition of
non-model static data, such as version number of the format among
other things.
Another point to note here is that, the string specified in the
custom format can also include fields from the Parent Models, thereby
allowing even Parent Model fields to be serialized.
Further the user will be well informed in the docs that he cannot
pass any arbitrary Django object when calling the serialize()
method with custom_format parameter, but only the Objects of type
for which the custom_format is defined using the ModelSerializer class.
If he does so we it will be flagged as error.
Also last but not the least, a select_related parameter will be
added to the serialize method, upon setting to True will automatically
serialize all the related models for this model. Serializing the
related model facilitates the reconstruction of the database tables
for the given model in case there exists any constraints. Further
the related models will be serialized in a default format.
Further if user knows what models might be selected when
select_related is true, he can provide the parameter like below:
related_custom_serializers={
"Model1" : Model1Serializer
"Model2" : Model2Serializer
}
While Serializing the related models, the serializer checks to see
if related_custom_serializers have items for the selected model
and serializes in that format if it exists. Example:
serializer.serialize("json", Poll.objects.all(),
custom_serializer=PollSerializer2, select_related=True,
related_custom_serializers={
"Model1" : Model1Serializer
"Model2" : Model2Serializer
}
)
(I am very skeptical about the use cases for the above feature, since
select_related is usually needed for round trips and rarely needed for
external applications. Nevertheless I propose it here, "Waiting for
further discussion")
NOTE: I must also admit that I am following the other proposal on the same
idea. Felt no point in hiding it. But it was my idea too to provide
custom format. I had started with this in my previous proposal itself I
feel. I was having very similar idea in mind when I used list and
dict separators, but got it wrong. After thinking of its weaknesses you said
for a day or so, I came up with the same idea, but was unfortunately late in
sending it, since you know I had already got it wrong 2 times :( Wanted to
tell something sensible 3rd time and was
preparing a more comprehensive solution. I hope it answers almost all the
questions you gave as braindump on the other proposal.
- Thanks and regards,
Madhusudan.C.S
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
