diff options
| author | Tony Nguyen | 2014-11-23 22:40:40 +0700 | 
|---|---|---|
| committer | Tony Nguyen | 2014-11-23 22:40:40 +0700 | 
| commit | c94d1e6d3ea76eb8bdd28717364e42d14e6722d7 (patch) | |
| tree | 878979993ac7ad0b494e6bd404e760f545dd8122 | |
| parent | f7de442ef4dc906d85249182d4a977b816873cec (diff) | |
| download | django-rest-framework-c94d1e6d3ea76eb8bdd28717364e42d14e6722d7.tar.bz2 | |
Fix typo "serailizers" to  "serializers"
| -rw-r--r-- | docs/topics/3.0-announcement.md | 22 | 
1 files changed, 11 insertions, 11 deletions
| diff --git a/docs/topics/3.0-announcement.md b/docs/topics/3.0-announcement.md index 7bbfba5b..694ad8a5 100644 --- a/docs/topics/3.0-announcement.md +++ b/docs/topics/3.0-announcement.md @@ -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
\ No newline at end of file +[mixins.py]: https://github.com/tomchristie/django-rest-framework/blob/master/rest_framework/mixins.py | 
