forked from orbit-oss/flask
Hyphenate "class-based"
makes it more readable
This commit is contained in:
parent
5cb50a46ee
commit
4aebc267bc
5 changed files with 11 additions and 11 deletions
4
CHANGES
4
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
|
||||
-------------
|
||||
|
|
|
|||
|
|
@ -476,7 +476,7 @@ Signals
|
|||
|
||||
.. _blinker: http://pypi.python.org/pypi/blinker
|
||||
|
||||
Class Based Views
|
||||
Class-Based Views
|
||||
-----------------
|
||||
|
||||
.. versionadded:: 0.7
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue