From d8dbd8679080035de4e785a8e7b998fb01f4052b Mon Sep 17 00:00:00 2001 From: Xavier Ordoquy Date: Sat, 10 Jan 2015 10:41:12 +0100 Subject: Update documentation --- tutorial/1-serialization/index.html | 4 ++-- tutorial/6-viewsets-and-routers/index.html | 1 + 2 files changed, 3 insertions(+), 2 deletions(-) (limited to 'tutorial') diff --git a/tutorial/1-serialization/index.html b/tutorial/1-serialization/index.html index a0e975d0..2363f355 100644 --- a/tutorial/1-serialization/index.html +++ b/tutorial/1-serialization/index.html @@ -512,7 +512,7 @@ class SnippetSerializer(serializers.Serializer):

The first part of the serializer class defines the fields that get serialized/deserialized. The create() and update() methods define how fully fledged instances are created or modified when calling serializer.save()

A serializer class is very similar to a Django Form class, and includes similar validation flags on the various fields, such as required, max_length and default.

-

The field flags can also control how the serializer should be displayed in certain circumstances, such as when rendering to HTML. The style={'type': 'textarea'} flag above is equivelent to using widget=widgets.Textarea on a Django Form class. This is particularly useful for controlling how the browsable API should be displayed, as we'll see later in the tutorial.

+

The field flags can also control how the serializer should be displayed in certain circumstances, such as when rendering to HTML. The {'base_template': 'textarea.html'} flag above is equivelent to using widget=widgets.Textarea on a Django Form class. This is particularly useful for controlling how the browsable API should be displayed, as we'll see later in the tutorial.

We can actually also save ourselves some time by using the ModelSerializer class, as we'll see later, but for now we'll keep our serializer definition explicit.

Working with Serializers

Before we go any further we'll familiarize ourselves with using our new Serializer class. Let's drop into the Django shell.

@@ -578,7 +578,7 @@ Open the file snippets/serializers.py again, and edit the Sni SnippetSerializer(): id = IntegerField(label='ID', read_only=True) title = CharField(allow_blank=True, max_length=100, required=False) - code = CharField(style={'type': 'textarea'}) + code = CharField(style={'base_template': 'textarea.html'}) linenos = BooleanField(required=False) language = ChoiceField(choices=[('Clipper', 'FoxPro'), ('Cucumber', 'Gherkin'), ('RobotFramework', 'RobotFramework'), ('abap', 'ABAP'), ('ada', 'Ada')... style = ChoiceField(choices=[('autumn', 'autumn'), ('borland', 'borland'), ('bw', 'bw'), ('colorful', 'colorful')... diff --git a/tutorial/6-viewsets-and-routers/index.html b/tutorial/6-viewsets-and-routers/index.html index 4babe707..254ab791 100644 --- a/tutorial/6-viewsets-and-routers/index.html +++ b/tutorial/6-viewsets-and-routers/index.html @@ -437,6 +437,7 @@ class SnippetViewSet(viewsets.ModelViewSet):

This time we've used the ModelViewSet class in order to get the complete set of default read and write operations.

Notice that we've also used the @detail_route decorator to create a custom action, named highlight. This decorator can be used to add any custom endpoints that don't fit into the standard create/update/delete style.

Custom actions which use the @detail_route decorator will respond to GET requests. We can use the methods argument if we wanted an action that responded to POST requests.

+

The URLs for custom actions by default depend on the method name itself. If you want to change the way url should be constructed, you can include url_path as a decorator keyword argument.

Binding ViewSets to URLs explicitly

The handler methods only get bound to the actions when we define the URLConf. To see what's going on under the hood let's first explicitly create a set of views from our ViewSets.

-- cgit v1.2.3