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
|
variable as well as ``SERVER_NAME`` are now properly used by the test client
|
||||||
as defaults.
|
as defaults.
|
||||||
- Added :attr:`flask.views.View.decorators` to support simpler decorating of
|
- 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
|
- Fixed an issue where the test client if used with the "with" statement did not
|
||||||
trigger the execution of the teardown handlers.
|
trigger the execution of the teardown handlers.
|
||||||
- Added finer control over the session cookie parameters.
|
- 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
|
might occur during request processing (for instance database connection
|
||||||
errors, timeouts from remote resources etc.).
|
errors, timeouts from remote resources etc.).
|
||||||
- Blueprints can provide blueprint specific error handlers.
|
- 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
|
Version 0.6.1
|
||||||
-------------
|
-------------
|
||||||
|
|
|
||||||
|
|
@ -476,7 +476,7 @@ Signals
|
||||||
|
|
||||||
.. _blinker: http://pypi.python.org/pypi/blinker
|
.. _blinker: http://pypi.python.org/pypi/blinker
|
||||||
|
|
||||||
Class Based Views
|
Class-Based Views
|
||||||
-----------------
|
-----------------
|
||||||
|
|
||||||
.. versionadded:: 0.7
|
.. versionadded:: 0.7
|
||||||
|
|
|
||||||
|
|
@ -148,7 +148,7 @@ classes:
|
||||||
a remote application that uses OAuth.
|
a remote application that uses OAuth.
|
||||||
|
|
||||||
What to use depends on what you have in mind. For the SQLite 3 extension
|
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.
|
manager object that handles opening and closing database connections.
|
||||||
|
|
||||||
The Extension Code
|
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
|
5. Finally, we add a `get_db` function that simplifies access to the context's
|
||||||
database.
|
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::
|
extension looks something like this::
|
||||||
|
|
||||||
from flask import Flask
|
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
|
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
|
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
|
views come into place. As the first step to convert this into a class
|
||||||
based view you would do this::
|
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()
|
return User.query.all()
|
||||||
|
|
||||||
This of course is not that helpful for such a small example, but it's good
|
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
|
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
|
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
|
and the :meth:`~flask.views.View.dispatch_request` method is called with
|
||||||
|
|
|
||||||
|
|
@ -3,7 +3,7 @@
|
||||||
flask.views
|
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.
|
:copyright: (c) 2011 by Armin Ronacher.
|
||||||
:license: BSD, see LICENSE for more details.
|
:license: BSD, see LICENSE for more details.
|
||||||
|
|
@ -50,7 +50,7 @@ class View(object):
|
||||||
#: A for which methods this pluggable view can handle.
|
#: A for which methods this pluggable view can handle.
|
||||||
methods = None
|
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
|
#: return value of as_view(). However since this moves parts of the
|
||||||
#: logic from the class declaration to the place where it's hooked
|
#: logic from the class declaration to the place where it's hooked
|
||||||
#: into the routing system.
|
#: into the routing system.
|
||||||
|
|
@ -89,7 +89,7 @@ class View(object):
|
||||||
view = decorator(view)
|
view = decorator(view)
|
||||||
|
|
||||||
# we attach the view class to the view function for two reasons:
|
# 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
|
# view this thing came from, secondly it's also used for instantiating
|
||||||
# the view class so you can actually replace it with something else
|
# the view class so you can actually replace it with something else
|
||||||
# for testing purposes and debugging.
|
# for testing purposes and debugging.
|
||||||
|
|
@ -120,7 +120,7 @@ class MethodViewType(type):
|
||||||
|
|
||||||
|
|
||||||
class MethodView(View):
|
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
|
particular methods. For instance if you implement a method called
|
||||||
:meth:`get` it means you will response to ``'GET'`` requests and
|
:meth:`get` it means you will response to ``'GET'`` requests and
|
||||||
the :meth:`dispatch_request` implementation will automatically
|
the :meth:`dispatch_request` implementation will automatically
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue