> 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)?
There will be different types of serializers like JSONSerializer,
YAMLSerializer, XMLSerializer etc . The end users will have to
subclass these, just like creating a new model.
While they need not be tied to specific models and can be used as
'generic' serializers, its finally down to the user's choice.
> 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?
It is for meta data of whole models (those implemented in the database
as "tables" and go through the start_model -> end_model cycle in the
current implementation of the serializer), basically a collection of
other fields, I believe the word 'model' is quite ambiguous in this
context. If there is a meta2_name method defined , the output would be
like this.
{
"name": " Output of meta2_name() here ",
... # fields of the model follow
}
> > 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?
The extras option allows the user to serialize properties of a model
that are not fields. These properties may be almost any standard
python attribute or method. Say, there is a model , Article, defined
like this:
class Article(models.Model):
headline = models.CharField(maxlength=100, default='Default
headline')
contents = models.TextField()
pub_date = models.DateTimeField()
...
def get_permalink():
#return some absolute URL
Eg: serialize(queryset, extras = ('Article.get_permalink') )
It takes an an iterable of strings in the format
"Object_Type.method_or_attribute_name".
>
> > -----------------------------------------------------------------
> > 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?
I would be leaving most of the existing fixture loading code intact
but add support for deserializing fixtures in an arbitrary format.
These fixtures should contain some minimum required data for
generating the model like content type, required fields etc.
> 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?
The data in the fields can be retrieved in the form of a python object
using the to_python method of the field as described here (
http://docs.djangoproject.com/en/dev/howto/custom-model-fields/ ). In
the case of the DateTimeField, it will be a datetime.datetime object.
Now, this is where the 'unicode_' methods come into play. By defining
a method "unicode_datetime_datetime()" in the serialiser , the
serialisation process for DateTimeFields can be overridden. The same
holds good for custom fields. If this naming convention based on the
python type is confusing, I can implement it according to the Django
field type.
--
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.
