mirror of
https://github.com/encode/django-rest-framework.git
synced 2024-11-11 04:07:39 +03:00
Merge branch 'master' of https://github.com/tomchristie/django-rest-framework
This commit is contained in:
commit
735d2257b4
|
@ -74,7 +74,7 @@ Default:
|
|||
|
||||
#### DEFAULT_PERMISSION_CLASSES
|
||||
|
||||
A list or tuple of permission classes, that determines the default set of permissions checked at the start of a view.
|
||||
A list or tuple of permission classes, that determines the default set of permissions checked at the start of a view. Permission must be granted by every class in the list.
|
||||
|
||||
Default:
|
||||
|
||||
|
|
|
@ -189,13 +189,13 @@ You can either return `non_field_errors` from the validate method by raising a s
|
|||
|
||||
def validate(self, attrs):
|
||||
# serializer.errors == {'non_field_errors': ['A non field error']}
|
||||
raise serailizers.ValidationError('A non field error')
|
||||
raise serializers.ValidationError('A non field error')
|
||||
|
||||
Alternatively if you want the errors to be against a specific field, use a dictionary of when instantiating the `ValidationError`, like so:
|
||||
|
||||
def validate(self, attrs):
|
||||
# serializer.errors == {'my_field': ['A field error']}
|
||||
raise serailizers.ValidationError({'my_field': 'A field error'})
|
||||
raise serializers.ValidationError({'my_field': 'A field error'})
|
||||
|
||||
This ensures you can still write validation that compares all the input fields, but that marks the error against a particular field.
|
||||
|
||||
|
@ -303,7 +303,7 @@ Alternatively, specify the field explicitly on the serializer class:
|
|||
model = MyModel
|
||||
fields = ('id', 'email', 'notes', 'is_admin')
|
||||
|
||||
The `read_only_fields` option remains as a convenient shortcut for the more common case.
|
||||
The `read_only_fields` option remains as a convenient shortcut for the more common case.
|
||||
|
||||
#### Changes to `HyperlinkedModelSerializer`.
|
||||
|
||||
|
@ -364,7 +364,7 @@ The `ListSerializer` class has now been added, and allows you to create base ser
|
|||
class MultipleUserSerializer(ListSerializer):
|
||||
child = UserSerializer()
|
||||
|
||||
You can also still use the `many=True` argument to serializer classes. It's worth noting that `many=True` argument transparently creates a `ListSerializer` instance, allowing the validation logic for list and non-list data to be cleanly separated in the REST framework codebase.
|
||||
You can also still use the `many=True` argument to serializer classes. It's worth noting that `many=True` argument transparently creates a `ListSerializer` instance, allowing the validation logic for list and non-list data to be cleanly separated in the REST framework codebase.
|
||||
|
||||
You will typically want to *continue to use the existing `many=True` flag* rather than declaring `ListSerializer` classes explicitly, but declaring the classes explicitly can be useful if you need to write custom `create` or `update` methods for bulk updates, or provide for other custom behavior.
|
||||
|
||||
|
@ -436,7 +436,7 @@ Here's a complete example of our previous `HighScoreSerializer`, that's been upd
|
|||
def to_internal_value(self, data):
|
||||
score = data.get('score')
|
||||
player_name = data.get('player_name')
|
||||
|
||||
|
||||
# Perform the data validation.
|
||||
if not score:
|
||||
raise ValidationError({
|
||||
|
@ -450,7 +450,7 @@ Here's a complete example of our previous `HighScoreSerializer`, that's been upd
|
|||
raise ValidationError({
|
||||
'player_name': 'May not be more than 10 characters.'
|
||||
})
|
||||
|
||||
|
||||
# Return the validated values. This will be available as
|
||||
# the `.validated_data` property.
|
||||
return {
|
||||
|
@ -463,7 +463,7 @@ Here's a complete example of our previous `HighScoreSerializer`, that's been upd
|
|||
'score': obj.score,
|
||||
'player_name': obj.player_name
|
||||
}
|
||||
|
||||
|
||||
def create(self, validated_data):
|
||||
return HighScore.objects.create(**validated_data)
|
||||
|
||||
|
@ -471,7 +471,7 @@ Here's a complete example of our previous `HighScoreSerializer`, that's been upd
|
|||
|
||||
The `BaseSerializer` class is also useful if you want to implement new generic serializer classes for dealing with particular serialization styles, or for integrating with alternative storage backends.
|
||||
|
||||
The following class is an example of a generic serializer that can handle coercing aribitrary objects into primitive representations.
|
||||
The following class is an example of a generic serializer that can handle coercing aribitrary objects into primitive representations.
|
||||
|
||||
class ObjectSerializer(serializers.BaseSerializer):
|
||||
"""
|
||||
|
@ -542,7 +542,7 @@ The `default` argument is also available and always implies that the field is no
|
|||
|
||||
#### Coercing output types.
|
||||
|
||||
The previous field implementations did not forcibly coerce returned values into the correct type in many cases. For example, an `IntegerField` would return a string output if the attribute value was a string. We now more strictly coerce to the correct return type, leading to more constrained and expected behavior.
|
||||
The previous field implementations did not forcibly coerce returned values into the correct type in many cases. For example, an `IntegerField` would return a string output if the attribute value was a string. We now more strictly coerce to the correct return type, leading to more constrained and expected behavior.
|
||||
|
||||
#### The `ListField` class.
|
||||
|
||||
|
@ -695,7 +695,7 @@ These classes are documented in the [Validators](../api-guide/validators.md) sec
|
|||
|
||||
The view logic for the default method handlers has been significantly simplified, due to the new serializers API.
|
||||
|
||||
#### Changes to pre/post save hooks.
|
||||
#### Changes to pre/post save hooks.
|
||||
|
||||
The `pre_save` and `post_save` hooks no longer exist, but are replaced with `perform_create(self, serializer)` and `perform_update(self, serializer)`.
|
||||
|
||||
|
@ -887,4 +887,4 @@ The 3.2 release is planned to introduce an alternative admin-style interface to
|
|||
|
||||
You can follow development on the GitHub site, where we use [milestones to indicate planning timescales](https://github.com/tomchristie/django-rest-framework/milestones).
|
||||
|
||||
[mixins.py]: https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/mixins.py
|
||||
[mixins.py]: https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/mixins.py
|
||||
|
|
|
@ -44,7 +44,9 @@ When that's all done we'll need to update our database tables.
|
|||
Normally we'd create a database migration in order to do that, but for the purposes of this tutorial, let's just delete the database and start again.
|
||||
|
||||
rm tmp.db
|
||||
python manage.py syncdb
|
||||
rm -r snippets/migrations
|
||||
python manage.py makemigrations snippets
|
||||
python manage.py migrate
|
||||
|
||||
You might also want to create a few different users, to use for testing the API. The quickest way to do this will be with the `createsuperuser` command.
|
||||
|
||||
|
|
|
@ -60,7 +60,7 @@ To see what's going on under the hood let's first explicitly create a set of vie
|
|||
|
||||
In the `urls.py` file we bind our `ViewSet` classes into a set of concrete views.
|
||||
|
||||
from snippets.views import SnippetViewSet, UserViewSet
|
||||
from snippets.views import SnippetViewSet, UserViewSet, api_root
|
||||
from rest_framework import renderers
|
||||
|
||||
snippet_list = SnippetViewSet.as_view({
|
||||
|
|
|
@ -237,13 +237,6 @@
|
|||
</div>
|
||||
<!-- END Content -->
|
||||
</div><!-- /.container -->
|
||||
|
||||
<footer>
|
||||
{% block footer %}
|
||||
<p>Sponsored by <a href="http://dabapps.com/">DabApps</a>.</p>
|
||||
{% endblock %}
|
||||
</footer>
|
||||
|
||||
</div><!-- ./wrapper -->
|
||||
|
||||
{% block script %}
|
||||
|
|
Loading…
Reference in New Issue
Block a user