From 8f35ac4f93c608eaced3f48a46e8922104e09182 Mon Sep 17 00:00:00 2001 From: Pascal Borreli Date: Tue, 28 May 2013 15:09:23 +0100 Subject: Fixed typos --- docs/api-guide/fields.md | 4 ++-- docs/api-guide/generic-views.md | 2 +- docs/api-guide/relations.md | 2 +- docs/api-guide/renderers.md | 6 +++--- docs/api-guide/routers.md | 2 +- docs/api-guide/serializers.md | 2 +- docs/api-guide/settings.md | 2 +- docs/api-guide/viewsets.md | 4 ++-- 8 files changed, 12 insertions(+), 12 deletions(-) (limited to 'docs/api-guide') diff --git a/docs/api-guide/fields.md b/docs/api-guide/fields.md index b3208eb1..92d2066d 100644 --- a/docs/api-guide/fields.md +++ b/docs/api-guide/fields.md @@ -204,7 +204,7 @@ If you want to override this behavior, you'll need to declare the `DateTimeField class Meta: model = Comment -Note that by default, datetime representations are deteremined by the renderer in use, although this can be explicitly overridden as detailed below. +Note that by default, datetime representations are determined by the renderer in use, although this can be explicitly overridden as detailed below. In the case of JSON this means the default datetime representation uses the [ECMA 262 date time string specification][ecma262]. This is a subset of ISO 8601 which uses millisecond precision, and includes the 'Z' suffix for the UTC timezone, for example: `2013-01-29T12:34:56.123Z`. @@ -226,7 +226,7 @@ Corresponds to `django.db.models.fields.DateField` * `format` - A string representing the output format. If not specified, this defaults to `None`, which indicates that python `date` objects should be returned by `to_native`. In this case the date encoding will be determined by the renderer. * `input_formats` - A list of strings representing the input formats which may be used to parse the date. If not specified, the `DATE_INPUT_FORMATS` setting will be used, which defaults to `['iso-8601']`. -Date format strings may either be [python strftime formats][strftime] which explicitly specifiy the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style dates should be used. (eg `'2013-01-29'`) +Date format strings may either be [python strftime formats][strftime] which explicitly specify the format, or the special string `'iso-8601'`, which indicates that [ISO 8601][iso8601] style dates should be used. (eg `'2013-01-29'`) ## TimeField diff --git a/docs/api-guide/generic-views.md b/docs/api-guide/generic-views.md index 1a060a32..20b9440b 100755 --- a/docs/api-guide/generic-views.md +++ b/docs/api-guide/generic-views.md @@ -71,7 +71,7 @@ The following attributes control the basic view behavior. The following attibutes are used to control pagination when used with list views. * `paginate_by` - The size of pages to use with paginated data. If set to `None` then pagination is turned off. If unset this uses the same value as the `PAGINATE_BY` setting, which defaults to `None`. -* `paginate_by_param` - The name of a query parameter, which can be used by the client to overide the default page size to use for pagination. If unset this uses the same value as the `PAGINATE_BY_PARAM` setting, which defaults to `None`. +* `paginate_by_param` - The name of a query parameter, which can be used by the client to override the default page size to use for pagination. If unset this uses the same value as the `PAGINATE_BY_PARAM` setting, which defaults to `None`. * `pagination_serializer_class` - The pagination serializer class to use when determining the style of paginated responses. Defaults to the same value as the `DEFAULT_PAGINATION_SERIALIZER_CLASS` setting. * `page_kwarg` - The name of a URL kwarg or URL query parameter which can be used by the client to control which page is requested. Defaults to `'page'`. diff --git a/docs/api-guide/relations.md b/docs/api-guide/relations.md index 99fe1083..af0687b9 100644 --- a/docs/api-guide/relations.md +++ b/docs/api-guide/relations.md @@ -237,7 +237,7 @@ Would serialize to a nested representation like this: 'album_name': 'The Grey Album', 'artist': 'Danger Mouse' 'tracks': [ - {'order': 1, 'title': 'Public Service Annoucement'}, + {'order': 1, 'title': 'Public Service Announcement'}, {'order': 2, 'title': 'What More Can I Say'}, {'order': 3, 'title': 'Encore'}, ... diff --git a/docs/api-guide/renderers.md b/docs/api-guide/renderers.md index 0161b54d..7e78318b 100644 --- a/docs/api-guide/renderers.md +++ b/docs/api-guide/renderers.md @@ -14,7 +14,7 @@ The set of valid renderers for a view is always defined as a list of classes. W The basic process of content negotiation involves examining the request's `Accept` header, to determine which media types it expects in the response. Optionally, format suffixes on the URL may be used to explicitly request a particular representation. For example the URL `http://example.com/api/users_count.json` might be an endpoint that always returns JSON data. -For more information see the documentation on [content negotation][conneg]. +For more information see the documentation on [content negotiation][conneg]. ## Setting the renderers @@ -69,7 +69,7 @@ If your API includes views that can serve both regular webpages and API response Renders the request data into `JSON`, using utf-8 encoding. -Note that non-ascii charaters will be rendered using JSON's `\uXXXX` character escape. For example: +Note that non-ascii characters will be rendered using JSON's `\uXXXX` character escape. For example: {"unicode black star": "\u2605"} @@ -89,7 +89,7 @@ The client may additionally include an `'indent'` media type parameter, in which Renders the request data into `JSON`, using utf-8 encoding. -Note that non-ascii charaters will not be character escaped. For example: +Note that non-ascii characters will not be character escaped. For example: {"unicode black star": "★"} diff --git a/docs/api-guide/routers.md b/docs/api-guide/routers.md index 6588d7e5..fd3a15d5 100644 --- a/docs/api-guide/routers.md +++ b/docs/api-guide/routers.md @@ -85,7 +85,7 @@ This router is similar to `SimpleRouter` as above, but additionally includes a d # Custom Routers -Implementing a custom router isn't something you'd need to do very often, but it can be useful if you have specfic 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 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. 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. diff --git a/docs/api-guide/serializers.md b/docs/api-guide/serializers.md index c83a0967..053a5eaf 100644 --- a/docs/api-guide/serializers.md +++ b/docs/api-guide/serializers.md @@ -104,7 +104,7 @@ When deserializing a list of items, errors will be returned as a list of diction #### Field-level validation -You can specify custom field-level validation by adding `.validate_` methods to your `Serializer` subclass. These are analagous to `.clean_` methods on Django forms, but accept slightly different arguments. +You can specify custom field-level validation by adding `.validate_` methods to your `Serializer` subclass. These are analogous to `.clean_` methods on Django forms, but accept slightly different arguments. They take a dictionary of deserialized attributes as a first argument, and the field name in that dictionary as a second argument (which will be either the name of the field or the value of the `source` argument to the field, if one was provided). diff --git a/docs/api-guide/settings.md b/docs/api-guide/settings.md index b00ab4c1..8d8c00cf 100644 --- a/docs/api-guide/settings.md +++ b/docs/api-guide/settings.md @@ -125,7 +125,7 @@ Default: `None` #### PAGINATE_BY_PARAM -The name of a query parameter, which can be used by the client to overide the default page size to use for pagination. If set to `None`, clients may not override the default page size. +The name of a query parameter, which can be used by the client to override the default page size to use for pagination. If set to `None`, clients may not override the default page size. Default: `None` diff --git a/docs/api-guide/viewsets.md b/docs/api-guide/viewsets.md index 31570d74..79364626 100644 --- a/docs/api-guide/viewsets.md +++ b/docs/api-guide/viewsets.md @@ -34,7 +34,7 @@ Let's define a simple viewset that can be used to list or retrieve all the users serializer = UserSerializer(user) return Response(serializer.data) -If we need to, we can bind this viewset into two seperate views, like so: +If we need to, we can bind this viewset into two separate views, like so: user_list = UserViewSet.as_view({'get': 'list'}) user_detail = UserViewSet.as_view({'get': 'retrieve'}) @@ -92,7 +92,7 @@ The default routers included with REST framework will provide routes for a stand def destroy(self, request, pk=None): pass -If you have ad-hoc methods that you need to be routed to, you can mark them as requiring routing using the `@link` or `@action` decorators. The `@link` decorator will route `GET` requests, and the `@action` decroator will route `POST` requests. +If you have ad-hoc methods that you need to be routed to, you can mark them as requiring routing using the `@link` or `@action` decorators. The `@link` decorator will route `GET` requests, and the `@action` decorator will route `POST` requests. For example: -- cgit v1.2.3