Upgrading from 0.4.x to 2.1.0

[DZ]

Greetings,

 I was using DRF 0.4 and Im having some problems with serialization which are difficult to describe. I breifly discussed with Tom and suggested to upgrade to DRF 2 to get support. I am basically only using the response mixin how is this different in DRF 2.0?

Many thankz

DZ

[Warwick Wilson]

This part of tutorial 3 reagrding mixins may be of assistance:
http://tomchristie.github.com/django-rest-framework/tutorial/3-class-based-views#using-mixins

I'm still getting my head around this framework myself so won't try to translate it for you.

[Tom Christie]

Maybe throw up an example of the kind of thing you're doing with your views at the moment?

Sounds like a fairly simple case?

[Marko Tibold]

Hey,

in 0.4 it was possible to define a method on a Resource and have that return value serailized. E.g.

class ImageResource(ModelResource):

    model = Image

    def can_edit(self, instance):

        return MyPermissionsClass.can_edit(self.view.user, instance)

With 2.X there's room to put this on the model, yet the model has no access to the request, nor the view, and therefore not to the user.

Should I put the logic in the view and 'augment' the response? Or is this something we might need to build?

Cheers,

Marko

[Tom Christie]

Hey Marko,

You can achieve the same functionality by creating a custom field (overriding to_native)

The request and view will be available as keys of the .context dict.

However, it might make sense to have a similar method-on-serializer API available.

The only question would be the best way to do that.

Perhaps have the 'source' argument support serializer methods...

    class MySerializer(serializers.Serializer):

        can_edit = Field(source='get_can_edit')

        def get_can_edit(self, obj):

            request = self.context['request']

            return MyPermissionsClass.can_edit(...)

[Marko Tibold]

> You can achieve the same functionality by creating a custom field (overriding to_native)
> The request and view will be available as keys of the .context dict.
>

Awesome, overriding .field_to_native() worked like a charm!

> However, it might make sense to have a similar method-on-serializer API available.
> The only question would be the best way to do that.
>
> Perhaps have the 'source' argument support serializer methods...
>
> class MySerializer(serializers.Serializer):
> can_edit = Field(source='get_can_edit')
>
> def get_can_edit(self, obj):
> request = self.context['request']

> return MyPermissionsClass.can_edit(…)

That looks even better! Should I add your first solution to the docs for now?

[Tom Christie]

> That looks even better! Should I add your first solution to the docs for now?

If you've got a good suggestion of what to add, and where.

There is currently this: http://django-rest-framework.org/api-guide/serializers.html#creating-custom-fields
I think the serializer docs will probably need a bit of re-jigging, into 3 separate sections:

Serializers

Serializer fields

Serializer relations

If and when that happens it'd probably make sense to move that 'custom fields' section out of 'Serializers' and into 'Serializer fields', although right now the fields section is probably a bit too long to do that.

[Marko Tibold]

Since this post is about upgrading from 0.4 to 2.X, here's a diff of a pull req to Django Fiber. It involves a port I wrote yesterday of the REST API from 0.3 to 2.X.

https://github.com/ridethepony/django-fiber/pull/142/files

If you've got a good suggestion of what to add, and where.

This section https://github.com/tomchristie/django-rest-framework/blob/master/docs/api-guide/fields.md#field

explains how to use a model-method with a  read-only Field. I think this would be a good place to add an example of using .field_to_native(). On the other hand, .field_to_native() is also already touched in serialzers.md

 

There is currently this: http://django-rest-framework.org/api-guide/serializers.html#creating-custom-fields
I think the serializer docs will probably need a bit of re-jigging, into 3 separate sections:

Serializers

Serializer fields

Serializer relations

I'd move all Field-customization docs to fields.md an reference it from serialziers.md where appropriate.