Merge pull request #392 from FND/docs

Hyphenate "class-based"

CHANGES

@@ -89,7 +89,7 @@ Released on September 29th 2011, codename Rakija
   variable as well as ``SERVER_NAME`` are now properly used by the test client
   as defaults.
 - Added :attr:`flask.views.View.decorators` to support simpler decorating of
-  pluggable (class based) views.
+  pluggable (class-based) views.
 - Fixed an issue where the test client if used with the "with" statement did not
   trigger the execution of the teardown handlers.
 - Added finer control over the session cookie parameters.
@@ -177,7 +177,7 @@ Released on June 28th 2011, codename Grappa
   might occur during request processing (for instance database connection
   errors, timeouts from remote resources etc.).
 - Blueprints can provide blueprint specific error handlers.
-- Implemented generic :ref:`views` (class based views).
+- Implemented generic :ref:`views` (class-based views).
 
 Version 0.6.1
 -------------

docs/api.rst

@@ -476,7 +476,7 @@ Signals
 
 .. _blinker: http://pypi.python.org/pypi/blinker
 
-Class Based Views
+Class-Based Views
 -----------------
 
 .. versionadded:: 0.7

docs/extensiondev.rst

@@ -148,7 +148,7 @@ classes:
     a remote application that uses OAuth.
 
 What to use depends on what you have in mind.  For the SQLite 3 extension
-we will use the class based approach because it will provide users with a
+we will use the class-based approach because it will provide users with a
 manager object that handles opening and closing database connections.
 
 The Extension Code
@@ -203,7 +203,7 @@ So here's what these lines of code do:
 5.  Finally, we add a `get_db` function that simplifies access to the context's
     database.
 
-So why did we decide on a class based approach here?  Because using our
+So why did we decide on a class-based approach here?  Because using our
 extension looks something like this::
 
     from flask import Flask

docs/views.rst

@@ -23,7 +23,7 @@ database and renders into a template::
 
 This is simple and flexible, but if you want to provide this view in a
 generic fashion that can be adapted to other models and templates as well
-you might want more flexibility.  This is where pluggable class based
+you might want more flexibility.  This is where pluggable class-based
 views come into place.  As the first step to convert this into a class
 based view you would do this::
 
@@ -70,7 +70,7 @@ this by itself is not helpful, so let's refactor the code a bit::
             return User.query.all()
 
 This of course is not that helpful for such a small example, but it's good
-enough to explain the basic principle.  When you have a class based view
+enough to explain the basic principle.  When you have a class-based view
 the question comes up what `self` points to.  The way this works is that
 whenever the request is dispatched a new instance of the class is created
 and the :meth:`~flask.views.View.dispatch_request` method is called with

flask/views.py

@@ -3,7 +3,7 @@
     flask.views
     ~~~~~~~~~~~
 
-    This module provides class based views inspired by the ones in Django.
+    This module provides class-based views inspired by the ones in Django.
 
     :copyright: (c) 2011 by Armin Ronacher.
     :license: BSD, see LICENSE for more details.
@@ -50,7 +50,7 @@ class View(object):
     #: A for which methods this pluggable view can handle.
     methods = None
 
-    #: The canonical way to decorate class based views is to decorate the
+    #: The canonical way to decorate class-based views is to decorate the
     #: return value of as_view().  However since this moves parts of the
     #: logic from the class declaration to the place where it's hooked
     #: into the routing system.
@@ -89,7 +89,7 @@ class View(object):
                 view = decorator(view)
 
         # we attach the view class to the view function for two reasons:
-        # first of all it allows us to easily figure out what class based
+        # first of all it allows us to easily figure out what class-based
         # view this thing came from, secondly it's also used for instantiating
         # the view class so you can actually replace it with something else
         # for testing purposes and debugging.
@@ -120,7 +120,7 @@ class MethodViewType(type):
 
 
 class MethodView(View):
-    """Like a regular class based view but that dispatches requests to
+    """Like a regular class-based view but that dispatches requests to
     particular methods.  For instance if you implement a method called
     :meth:`get` it means you will response to ``'GET'`` requests and
     the :meth:`dispatch_request` implementation will automatically