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
|
|
@ -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
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue