diff options
| author | Veronica Lynn | 2013-08-07 14:00:06 -0400 | 
|---|---|---|
| committer | Veronica Lynn | 2013-08-07 14:00:06 -0400 | 
| commit | 4d8d2340be4de905af3488dc721c7b94b1371ef0 (patch) | |
| tree | 38b60bc6099d0af27a4a7fcc5dbaf91ca3d76b26 /docs/api-guide | |
| parent | b52beb0734e167349b2cf397047a2ec7fe304b35 (diff) | |
| download | django-rest-framework-4d8d2340be4de905af3488dc721c7b94b1371ef0.tar.bz2 | |
Fixed typos in a bunch of docs
Diffstat (limited to 'docs/api-guide')
| -rw-r--r-- | docs/api-guide/permissions.md | 2 | ||||
| -rw-r--r-- | docs/api-guide/relations.md | 8 | ||||
| -rw-r--r-- | docs/api-guide/renderers.md | 2 | ||||
| -rw-r--r-- | docs/api-guide/responses.md | 4 | ||||
| -rw-r--r-- | docs/api-guide/reverse.md | 2 | ||||
| -rw-r--r-- | docs/api-guide/routers.md | 2 | ||||
| -rw-r--r-- | docs/api-guide/serializers.md | 6 | ||||
| -rw-r--r-- | docs/api-guide/settings.md | 4 | ||||
| -rw-r--r-- | docs/api-guide/testing.md | 2 | ||||
| -rw-r--r-- | docs/api-guide/views.md | 2 | 
10 files changed, 17 insertions, 17 deletions
| diff --git a/docs/api-guide/permissions.md b/docs/api-guide/permissions.md index 5597886d..096ef369 100644 --- a/docs/api-guide/permissions.md +++ b/docs/api-guide/permissions.md @@ -147,7 +147,7 @@ If you need to test if a request is a read operation or a write operation, you s  **Note**: In versions 2.0 and 2.1, the signature for the permission checks always included an optional `obj` parameter, like so: `.has_permission(self, request, view, obj=None)`.  The method would be called twice, first for the global permission checks, with no object supplied, and second for the object-level check when required. -As of version 2.2 this signature has now been replaced with two separate method calls, which is more explict and obvious.  The old style signature continues to work, but it's use will result in a `PendingDeprecationWarning`, which is silent by default.  In 2.3 this will be escalated to a `DeprecationWarning`, and in 2.4 the old-style signature will be removed. +As of version 2.2 this signature has now been replaced with two separate method calls, which is more explicit and obvious.  The old style signature continues to work, but its use will result in a `PendingDeprecationWarning`, which is silent by default.  In 2.3 this will be escalated to a `DeprecationWarning`, and in 2.4 the old-style signature will be removed.  For more details see the [2.2 release announcement][2.2-announcement]. diff --git a/docs/api-guide/relations.md b/docs/api-guide/relations.md index 50c9bc54..829a3c54 100644 --- a/docs/api-guide/relations.md +++ b/docs/api-guide/relations.md @@ -39,7 +39,7 @@ In order to explain the various types of relational fields, we'll use a couple o  ## RelatedField -`RelatedField` may be used to represent the target of the relationship using it's `__unicode__` method. +`RelatedField` may be used to represent the target of the relationship using its `__unicode__` method.  For example, the following serializer. @@ -71,7 +71,7 @@ This field is read only.  ## PrimaryKeyRelatedField -`PrimaryKeyRelatedField` may be used to represent the target of the relationship using it's primary key. +`PrimaryKeyRelatedField` may be used to represent the target of the relationship using its primary key.  For example, the following serializer: @@ -252,7 +252,7 @@ If you want to implement a read-write relational field, you must also implement  ## Example -For, example, we could define a relational field, to serialize a track to a custom string representation, using it's ordering, title, and duration. +For, example, we could define a relational field, to serialize a track to a custom string representation, using its ordering, title, and duration.      import time @@ -386,7 +386,7 @@ For more information see [the Django documentation on generic relations][generic  By default, relational fields that target a ``ManyToManyField`` with a  ``through`` model specified are set to read-only. -If you exlicitly specify a relational field pointing to a +If you explicitly specify a relational field pointing to a  ``ManyToManyField`` with a through model, be sure to set ``read_only``  to ``True``. diff --git a/docs/api-guide/renderers.md b/docs/api-guide/renderers.md index b434efe9..bb3d2015 100644 --- a/docs/api-guide/renderers.md +++ b/docs/api-guide/renderers.md @@ -241,7 +241,7 @@ This renderer is used for rendering HTML multipart form data.  **It is not suita  To implement a custom renderer, you should override `BaseRenderer`, set the `.media_type` and `.format` properties, and implement the `.render(self, data, media_type=None, renderer_context=None)` method. -The method should return a bytestring, which wil be used as the body of the HTTP response. +The method should return a bytestring, which will be used as the body of the HTTP response.  The arguments passed to the `.render()` method are: diff --git a/docs/api-guide/responses.md b/docs/api-guide/responses.md index 399b7c23..5a42aa92 100644 --- a/docs/api-guide/responses.md +++ b/docs/api-guide/responses.md @@ -24,7 +24,7 @@ Unless you want to heavily customize REST framework for some reason, you should  Unlike regular `HttpResponse` objects, you do not instantiate `Response` objects with rendered content.  Instead you pass in unrendered data, which may consist of any Python primitives. -The renderers used by the `Response` class cannot natively handle complex datatypes such as Django model instances, so you need to serialize the data into primative datatypes before creating the `Response` object. +The renderers used by the `Response` class cannot natively handle complex datatypes such as Django model instances, so you need to serialize the data into primitive datatypes before creating the `Response` object.  You can use REST framework's `Serializer` classes to perform this data serialization, or use your own custom serialization. @@ -54,7 +54,7 @@ The rendered content of the response.  The `.render()` method must have been cal  ## .template_name -The `template_name`, if supplied.  Only required if `HTMLRenderer` or some other custom template renderer is the accepted renderer for the reponse. +The `template_name`, if supplied.  Only required if `HTMLRenderer` or some other custom template renderer is the accepted renderer for the response.  ## .accepted_renderer diff --git a/docs/api-guide/reverse.md b/docs/api-guide/reverse.md index 19930dc3..94262366 100644 --- a/docs/api-guide/reverse.md +++ b/docs/api-guide/reverse.md @@ -17,7 +17,7 @@ The advantages of doing so are:  REST framework provides two utility functions to make it more simple to return absolute URIs from your Web API. -There's no requirement for you to use them, but if you do then the self-describing API will be able to automatically hyperlink it's output for you, which makes browsing the API much easier. +There's no requirement for you to use them, but if you do then the self-describing API will be able to automatically hyperlink its output for you, which makes browsing the API much easier.  ## reverse diff --git a/docs/api-guide/routers.md b/docs/api-guide/routers.md index 7f53f109..072a2e79 100644 --- a/docs/api-guide/routers.md +++ b/docs/api-guide/routers.md @@ -96,7 +96,7 @@ As with `SimpleRouter` the trailing slashes on the URL routes can be removed by  # Custom Routers -Implementing a custom router isn't something you'd need to do very often, but it can be useful if you have specific requirements about how the your URLs for your API are strutured.  Doing so allows you to encapsulate the URL structure in a reusable way that ensures you don't have to write your URL patterns explicitly for each new view. +Implementing a custom router isn't something you'd need to do very often, but it can be useful if you have specific requirements about how the your URLs for your API are structured.  Doing so allows you to encapsulate the URL structure in a reusable way that ensures you don't have to write your URL patterns explicitly for each new view.  The simplest way to implement a custom router is to subclass one of the existing router classes.  The `.routes` attribute is used to template the URL patterns that will be mapped to each viewset. The `.routes` attribute is a list of `Route` named tuples. diff --git a/docs/api-guide/serializers.md b/docs/api-guide/serializers.md index a1f0853e..bbc8d019 100644 --- a/docs/api-guide/serializers.md +++ b/docs/api-guide/serializers.md @@ -403,7 +403,7 @@ You can change the field that is used for object lookups by setting the `lookup_  Not that the `lookup_field` will be used as the default on *all* hyperlinked fields, including both the URL identity, and any hyperlinked relationships. -For more specfic requirements such as specifying a different lookup for each field, you'll want to set the fields on the serializer explicitly.  For example: +For more specific requirements such as specifying a different lookup for each field, you'll want to set the fields on the serializer explicitly.  For example:      class AccountSerializer(serializers.HyperlinkedModelSerializer):          url = serializers.HyperlinkedIdentityField( @@ -429,7 +429,7 @@ You can create customized subclasses of `ModelSerializer` or `HyperlinkedModelSe  Doing so should be considered advanced usage, and will only be needed if you have some particular serializer requirements that you often need to repeat. -## Dynamically modifiying fields +## Dynamically modifying fields  Once a serializer has been initialized, the dictionary of fields that are set on the serializer may be accessed using the `.fields` attribute.  Accessing and modifying this attribute allows you to dynamically modify the serializer. @@ -449,7 +449,7 @@ For example, if you wanted to be able to set which fields should be used by a se              # Don't pass the 'fields' arg up to the superclass              fields = kwargs.pop('fields', None) -            # Instatiate the superclass normally +            # Instantiate the superclass normally              super(DynamicFieldsModelSerializer, self).__init__(*args, **kwargs)              if fields: diff --git a/docs/api-guide/settings.md b/docs/api-guide/settings.md index 7b114983..0be0eb24 100644 --- a/docs/api-guide/settings.md +++ b/docs/api-guide/settings.md @@ -28,7 +28,7 @@ you should use the `api_settings` object.  For example.      print api_settings.DEFAULT_AUTHENTICATION_CLASSES -The `api_settings` object will check for any user-defined settings, and otherwise fallback to the default values.  Any setting that uses string import paths to refer to a class will automatically import and return the referenced class, instead of the string literal. +The `api_settings` object will check for any user-defined settings, and otherwise fall back to the default values.  Any setting that uses string import paths to refer to a class will automatically import and return the referenced class, instead of the string literal.  --- @@ -165,7 +165,7 @@ Default: `'multipart'`  The renderer classes that are supported when building test requests. -The format of any of these renderer classes may be used when contructing a test request, for example: `client.post('/users', {'username': 'jamie'}, format='json')` +The format of any of these renderer classes may be used when constructing a test request, for example: `client.post('/users', {'username': 'jamie'}, format='json')`  Default: diff --git a/docs/api-guide/testing.md b/docs/api-guide/testing.md index 40b07763..92f8d54a 100644 --- a/docs/api-guide/testing.md +++ b/docs/api-guide/testing.md @@ -34,7 +34,7 @@ To support a wider set of request formats, or change the default format, [see th  #### Explicitly encoding the request body -If you need to explictly encode the request body, you can do so by setting the `content_type` flag.  For example: +If you need to explicitly encode the request body, you can do so by setting the `content_type` flag.  For example:      request = factory.post('/notes/', json.dumps({'title': 'new idea'}), content_type='application/json') diff --git a/docs/api-guide/views.md b/docs/api-guide/views.md index 683222d1..15581e09 100644 --- a/docs/api-guide/views.md +++ b/docs/api-guide/views.md @@ -110,7 +110,7 @@ You won't typically need to override this method.  ### .finalize_response(self, request, response, \*args, **kwargs) -Ensures that any `Response` object returned from the handler method will be rendered into the correct content type, as determined by the content negotation. +Ensures that any `Response` object returned from the handler method will be rendered into the correct content type, as determined by the content negotiation.  You won't typically need to override this method. | 
